home *** CD-ROM | disk | FTP | other *** search
/ Visual Cafe 3 / Visual Cafe 3.ISO / Vcafe / Main.bin / CHANGES < prev    next >
Text File  |  1998-10-29  |  106KB  |  2,759 lines
  1.                          
  2.                 CHANGES
  3.  
  4.                Java(tm) Development Kit
  5.                    JDK(tm) 1.1.7A Software
  6.                          
  7. CHANGES summarizes the changes between public JDK software releases for
  8. the Java Platform 1.1. CHANGES contains the following sections:
  9.  
  10.     - What Version Do I Have?
  11.     - Bug Parade
  12.     - The JDK 1.1.x Compatibility Page
  13.     - Changes in the JDK 1.1.7A Software
  14.     - Changes from JDK 1.1.6 to JDK 1.1.7
  15.     - Changes from JDK 1.1.5 to JDK 1.1.6
  16.     - Changes from JDK 1.1.4 to JDK 1.1.5
  17.     - Changes from JDK 1.1.3 to JDK 1.1.4
  18.     - Changes from JDK 1.1.2 to JDK 1.1.3
  19.     - Changes from JDK 1.1.1 to JDK 1.1.2
  20.     - Changes from JDK 1.1_Final to JDK 1.1.1_Final
  21.     - Changes from JDK 1.1beta3  to JDK 1.1_Final
  22.     - Changes from JDK 1.1beta2  to JDK 1.1beta3
  23.     - Changes from the original JDK 1.1beta to JDK 1.1beta2
  24.  
  25.  
  26. =======================================================================
  27. What Version Do I Have?
  28. -----------------------------------------------------------------------
  29.  
  30. To determine the version of your currently installed JDK software,
  31. execute:
  32.  
  33.           java -version
  34.  
  35. =======================================================================
  36. Bug Parade
  37. -----------------------------------------------------------------------
  38.  
  39. This document summarizes only the most important bug fixes. For
  40. detailed information on bug fixes and open bugs, visit Bug Parade on
  41. the Java Developer's Connection web site. Bug Parade also allows you to
  42. file your own bug reports, add comments to existing bug reports, and
  43. vote for the bugs you consider most important. Bug Parade is located at
  44.  
  45.     http://java.sun.com/jdc/bugParade/
  46.  
  47.  
  48. =======================================================================
  49. The JDK 1.1.x Compatibility Page
  50. -----------------------------------------------------------------------
  51.  
  52. CHANGES does not address version compatibility issues. Real and
  53. potential compatibility problems are addressed on the JDK 1.1
  54. Compatibility Page at 
  55.  
  56.     http://java.sun.com/products/jdk/1.1/compatibility.html
  57.  
  58. The Compatibility Page is available only from the Java Software web
  59. site. 
  60.  
  61.  
  62. =======================================================================
  63. Changes in the JDK 1.1.7A Software
  64. -----------------------------------------------------------------------
  65.  
  66. The JDK 1.1.7A software contains these changes:
  67.  
  68. ________________
  69. COPY & PASTE BUG - A bug in the native implementation of the 
  70. setContents method of java.awt.datatransfer.Clipboard prevented 
  71. copying to the clipboard on Windows 95 and Windows 98 platforms. This 
  72. problem has been fixed in the JDK 1.1.7A software. [Bug 4177171]
  73.  
  74. _______________________
  75. CHOICEBOX SCROLLBAR BUG - A bug in the Windows JDK software prevented 
  76. choicebox scrollbars from working in modal dialog windows. This 
  77. problem is fixed in the JDK 1.1.7A software. [Bug 4178390]
  78.  
  79. _______________________
  80. EURO SUPPORT ON WINDOWS - Support for the new Euro currency character 
  81. has been added for the Windows version of the Java Development Kit. See 
  82. the EURO SUPPORT section of the JDK README for details. The JDK README 
  83. is located in the top level of the JDK software and on-line at 
  84.  
  85.     http://java.sun.com/products/JDK/1.1/README
  86.  
  87. _______________________
  88. EURO SUPPORT ON SOLARIS - The euro variants of some locale names in 
  89. the Solaris euro-support patch are not the same as the corresponding 
  90. locale names in the Solaris JDK software. A locale-mapping mechanism 
  91. has been added to the Solaris JDK software to ensure proper mapping 
  92. of patch locale names to JDK locale names. [Bug 4182062] 
  93.  
  94. _______________________
  95. EURO SUPPORT ON SOLARIS - A font properties file for support of the 
  96. euro currency symbol (encoding ISO 8859_15) has been added to the 
  97. Solaris JDK software. Note that versions of Solaris prior to 2.7 will 
  98. require a patch in order for euro support to be functional.  See the 
  99. EURO SUPPORT section of the JDK 1.1.7A README file. [Bug 4181915]
  100.  
  101.  
  102. =======================================================================
  103. Changes from JDK 1.1.6 to JDK 1.1.7
  104. -----------------------------------------------------------------------
  105.  
  106. JDK 1.1.7 is a maintenance release. The following list summarizes some 
  107. significant changes in JDK 1.1.7.
  108.  
  109. ______________
  110. VERSION NUMBER - The version number for this release is "JDK1.1.7".
  111.  
  112. ________________
  113. DEFAULT ENCODING - On Win32 systems, the default encoding for western
  114. locales is now Cp1252 (Windows Latin-1). On Solaris, the default
  115. encoding for western locales remains ISO8859_1.
  116.  
  117. This change in default encoding will break some programs that
  118. unintentionally depend on features of ISO8859_1. An example of this
  119. kind of problem is documented in the README, under "Data Transfer
  120. Problems on Windows." 
  121.  
  122. ____________
  123. EURO SUPPORT - The Solaris JDK 1.1.7 software includes support for the 
  124. new European Union currency, the euro. No APIs or existing locale 
  125. resources were changed, though a number of new locale resources were 
  126. added. A number of existing encodings were changed, and new encodings 
  127. were added. See the README for details.
  128.  
  129. _______
  130. UNICODE - In order to support the euro currency character, Unicode
  131. support was upgraded from 2.0.14 to 2.1.2.
  132.  
  133. _______________________
  134. IMPROVED CLASS VERIFIER - To support additional character encodings,
  135. the class verifier was re-engineered. The result is a smaller, faster
  136. class verifier that will improve the performance of all programs.
  137.  
  138. _______________
  139. CLASS LOAD HOOK - A new class load hook supports tools that add
  140. profiling or debugging information to class file data. See the README
  141. for details.
  142.  
  143. _______________
  144. SOLARIS SUPPORT - JDK 1.1.7 software is supported on Solaris 2.5.1 and
  145. 2.6. JDK 1.1.7 was not tested on Solaris 2.4, which is no longer a
  146. supported system platform.
  147.  
  148. _________
  149. BUG FIXES - This release incorporates a large number of bug fixes.
  150. These include a large number of fixes to the AWT classes, and a
  151. significant number of fixes to the internationalization classes and the
  152. JIT.
  153.  
  154.  
  155. =======================================================================
  156. Changes from JDK 1.1.5 to JDK 1.1.6
  157. -----------------------------------------------------------------------
  158.  
  159. JDK 1.1.6 is a maintenance release. The following list summarizes some 
  160. significant changes in JDK 1.1.6.
  161.  
  162. ______________
  163. VERSION NUMBER - The version number for this release is "JDK1.1.6".
  164.  
  165. ________________________________________________
  166. PERFORMANCE AND INTERNATIONALIZATION ENHANCEMENTS - JDK 1.1.6
  167. incorporates a significant amount of work designed to improve overall
  168. performance and support for internationalization.
  169.  
  170. _______________________________
  171. SERIALIZATION PROTOCOL VERSIONS
  172.  
  173. Programs based on JDK 1.1.6 can read serialization streams written in
  174. PROTOCOL_VERSION_2. This feature ensures object stream compatibility
  175. between JDK 1.2 and JDK 1.1. No changes were made the API, and no
  176. source code changes are required.
  177.  
  178. Because the API is frozen, the ability to write PROTOCOL_VERSION_2
  179. streams will not be added to JDK software version 1.1. This feature is
  180. available in JDK software version 1.2 Beta3, or later versions.
  181.  
  182. ____________
  183. JIT COMPILER - The Win32 version of JDK 1.1.6 includes a Just In Time
  184. bytecode compiler, or JIT. This is a production-quality version of the
  185. JIT previously provided in the Win32 Performance Pack.
  186.  
  187. Both launcher tools (java and jre) now use the JIT by default. The java
  188. launcher tool has a new option, -nojit, which disables the JIT. This
  189. option was implemented for jre in a previous release.
  190.  
  191. _____________________
  192. SOLARIS AWT EVENT BUG - In earler versions of the JDK, multithreading
  193. programs running on Solaris might experience errors, including program
  194. crashes, if events were dispatched to AWT controls that had already
  195. been removed from the screen. This bug is fixed in JDK 1.1.6. [Bug
  196. 4041235]
  197.  
  198. ____________________________________
  199. DRAG GENERATES INCORRECT MOUSE_ENTER - In earlier versions of the JDK,
  200. draging the mouse pointer across a control could generate a MOUSE_ENTER
  201. event with incorrect coordinates. This bug is fixed in JDK 1.1.6. [Bug
  202. 4092421]
  203.  
  204. _________________________
  205. INCORRECT UNICODE DISPLAY - In earlier versions of the JDK, the Unicode
  206. sequence "\u301c" was not mapped to the correct character. This bug is
  207. fixed in JDK 1.1.6. [Bug 4023097]
  208.  
  209. ______________________
  210. WINDOWS 95 MEMORY LEAK - In earlier versions of the JDK, programs
  211. running on Windows 95 would fail to deallocate a buffer allocated by
  212. java.awt.TextComponent.getText(). This bug is fixed in JDK 1.1.6. [Bug
  213. 4068639]
  214.  
  215. __________________________
  216. THREAD-RELATED MEMORY LEAK - In JDK 1.1.5, information about a thread
  217. was not discarded when the thread died. This resulted in severe memory
  218. leaks in programs that created and destroyed large numbers of threads.
  219. This bug is fixed in JDK 1.1.6. [Bug 4102107]
  220.  
  221. _________________________
  222. RMI SERVER FAILS TO RETRY - In earlier versions of the JDK, an RMI
  223. accept thread would silently die if an accept failed and no
  224. RMIFailureHandler is installed. The correct behavior in this situation
  225. is to attempt re-creation of the socket. This bug is fixed in JDK
  226. 1.1.6. [Bug 4096750]
  227.  
  228. ____________________________________
  229. UNNECESSARY RESOURCE BUNDLE MESSAGES - In earlier versions of the JDK,
  230. a resource bundle search produced an error message for every
  231. unsuccessful attempt to open a bundle. This could produce a large
  232. number of error messages, even in a successful search. This behavior is
  233. moderated in JDK 1.1.6. [Bug 4050902]
  234.  
  235. ___________________
  236. UNNECESSARY REPAINT - In earlier versions of the JDK, programs running
  237. on Win32 systems with 256-color displays would sometimes repaint
  238. unnecessarily after closing a modal dialog. This bug is fixed in JDK
  239. 1.1.6. [Bug 4088416]
  240.  
  241. ________________
  242. SLOW LIST UPDATE - In earlier versions of the JDK, programs running on
  243. Windows 95 would update list boxes very slowly. This bug has been fixed
  244. in JDK 1.1.6 [Bug 4079288]
  245.  
  246. ___________
  247. WINSOCK 2.0 - JDK software no longer includes Microsoft WinSock 2.0.
  248. For more information, see the README file.
  249.  
  250.  
  251. =======================================================================
  252. Changes from JDK 1.1.4 to JDK 1.1.5
  253. -----------------------------------------------------------------------
  254.  
  255. JDK 1.1.5 is a maintenance release. The following list summarizes some 
  256. significant changes in JDK 1.1.5.
  257.  
  258. ______________
  259. VERSION NUMBER - The version number for this release is "JDK1.1.5".
  260.  
  261. _________________
  262. AWT SCROLLBAR BUG - In some situations, the scrollbar would not 
  263. stop scrolling on earlier versions of JDK 1.1 for Solaris-SPARC. This 
  264. problem has been fixed in JDK 1.1.5. [Bug 4048060]
  265.  
  266. ______________
  267. AWT CHOICE BUG - In earlier versions of the JDK, Choice.removeAll() 
  268. followed by Choice.addItem would result in a core dump in some 
  269. situations. This problem has been fixed in JDK 1.1.5. [Bug 4064823]
  270.  
  271. __________
  272. SOCKET BUG - On win95, under certain circumstances such as heavy 
  273. network load, closing sockets could cause the connection to be reset, 
  274. disturbing the connection's peer. This bug has been fixed in JDK 1.1.5.
  275. [Bug 4069782]
  276.  
  277. ________________ 
  278. APPLETVIEWER BUG - In earlier JDKs, the appletviewer would hang while 
  279. running under jdb. This bug has been fixed in JDK 1.1.5. [Bug 4061955]
  280.  
  281. ________________
  282. MODAL DIALOG BUG - Hiding and then showing modal dialogs resulted in 
  283. crash-causing race conditions in earlier JDKs. This bug has been fixed 
  284. in JDK 1.1.5. [Bug 4068620]
  285.  
  286. _____________________________
  287. AWT LIGHTWEIGHT COMPONENT BUG - In a FOCUS_GAINED handler for a 
  288. lightweight component, a call to requestFocus() to shift the focus to 
  289. another view would fail. This bug has been fixed in JDK 1.1.5. 
  290. [Bug 4070597]
  291.  
  292. _________________________________
  293. ARRAY INITIALIZATION OPTIMIZATION - Beginning with JDK 1.1.5, the 
  294. compiler does not generate inline code to fill the values of newly 
  295. created arrays, because such arrays are already filled with the 
  296. default values. This optimization saves half a megabyte in the 
  297. compressed classes.zip file.  [Bugs 4017848, 4080908]
  298.  
  299. _______________
  300. AWT REPAINT BUG - When several repaints are issued together in 
  301. previous JDKs, some repaints would not be carried out. This problem 
  302. has been fixed in JDK 1.1.5.  [Bug 4073091]
  303.  
  304. _______________
  305. AWT THREADS BUG - Repeatedly adding and removing components using 
  306. threads sometimes caused the VM to crash in earlier JDKs. This bug 
  307. has been fixed in JDK 1.1.5.  [Bug 4073623] 
  308.  
  309. ________________
  310. JAVA.NET.URL BUG - In JDK 1.1.4, the method setURLStreamHandlerFactory 
  311. in java.net.url did not clear the handlers cache. This meant that any 
  312. URL constructed prior to calling that method would use an old handler. 
  313. This bug has been fixed in JDK 1.1.5.  [Bug 4074245]
  314.  
  315. _________________________
  316. GETRESOURCE DIRECTORY BUG - JDK 1.1.4 introduced a bug in which a 
  317. directory path (e.g. myImages/) would be used to obtain a URL via 
  318. getResource().  This bug was only present on the win32 platform, and 
  319. was present in some conditions when using Beans.instantiate(). This bug 
  320. has been fixed in JDK 1.1.5 [Bug 4080478]
  321.  
  322. _______________
  323. GETRESOURCE BUG - In JDK 1.1.4, the URL returned by getResource() was 
  324. incorrect. This problem has been fixed in JDK 1.1.5 [Bug 4026780].  
  325. For details on getResource() and getResourceAsStream() see the document 
  326. at http://java.sun.com/products/jdk/1.1/docs/guide/misc/resources.html.
  327.  
  328. _____________
  329. AWT EVENT BUG - In JDK 1.1.4, when the mouse was moved from a 
  330. lightweight component directly to a non-lightweight component, a 
  331. MouseMove event was not generated to the host container. This bug has 
  332. been fixed in JDK 1.1.5.  [Bug 4065565]
  333.  
  334. _____________
  335. AWT PANEL BUG - In JDK 1.1.4, components derived from Panel had an 
  336. extra pixel in their border. Among other things, this could cause 
  337. problems with calculation of BorderLayout element heights. This 
  338. bug has been fixed in JDK 1.1.5.  [Bugs 4062779, 4064468]
  339.  
  340. _______________
  341. AWT MENUBAR BUG - On Solaris versions of JDK 1.1.4, the MenuBar was 
  342. not always correctly resized when MenuBar labels changed length. This 
  343. problem has been fixed in JDK 1.1.5.  [Bug 4071628]
  344.  
  345. _______________
  346. AWT MENUBAR BUG - On Windows versions of JDK 1.1.4, a MenuBar did 
  347. not correctly resize itself when all items were removed from it and 
  348. new items added to it. This bug has been fixed in JDK 1.1.5. 
  349. [Bug 4071438]
  350.  
  351. _____________
  352. AWT EVENT BUG - On Windows versions of JDK 1.1.4, spurious mouse press 
  353. events were sometimes generated during mouse exit events. This bug has 
  354. been fixed in JDK 1.1.5.  [Bug 4038721]
  355.  
  356. ________________
  357. AWT PRINTJOB BUG - In earlier JDKs, java.awt.PrintJob.getPageResolution 
  358. and java.awt.PrintJob.GetPageDimension would return incorrect values in 
  359. some circumstances. This bug has been fixed in JDK 1.1.5. [Bug 4049865]
  360.  
  361.  
  362. =======================================================================
  363. Changes from JDK 1.1.3 to JDK 1.1.4
  364. -----------------------------------------------------------------------
  365.  
  366. JDK 1.1.4 is a maintenance release. The following list summarizes some 
  367. significant changes in JDK 1.1.4.
  368. ______________
  369. VERSION NUMBER - The version number for this release is "JDK1.1.4".
  370.  
  371. ____________________
  372. JAVA TEXT BOUNDS BUG - The DateFormat.parse() unexpectedly threw a 
  373. StringIndexOutOfBoundsException rather than the expected 
  374. FormatException.  This bug has been fixed in JDK 1.1.4.  [Bug 4031620]
  375.  
  376. _________________
  377. AWT COMPONENT BUG - In the Windows version of JDK 1.1.3, incorrect 
  378. character codes from non-101 keyboards where being received, causing 
  379. the incorrect generation of a KeyPressed/Release event.  This bug has 
  380. been fixed in JDK 1.1.4.  [Bugs 4051910, 4053800]
  381.  
  382. __________________
  383. AWT POPUP MENU BUG - Removing menus from PopupMenus on Solaris versions 
  384. of JDK 1.1.2 and JDK 1.1.3 caused a core dump. This problem has been 
  385. corrected in JDK 1.1.4.  [Bug 4054479]
  386.  
  387. __________
  388. AWT IM BUG - In the Solaris version on the JDK 1.1.1, the IM status 
  389. region was created inside of the AWT window and broke the layout of the 
  390. window.  This bug has been fixed in JDK 1.1.4.  [Bug 4041569]
  391.  
  392. ____________
  393. AWT MENU BUG - In the Solaris version of the JDK 1.1.2 & JDK 1.1.3 a 
  394. core dump would result when removing MenuItems from submenus on 
  395. PopuMenus.  This bug has been fixed in JDK 1.1.4.  [Bug 4054479]
  396.  
  397. ____________________
  398. AWT MODAL DIALOG BUG - Calls to the hide() method in the Win32 version 
  399. of JDK 1.1.3 does not always hide the modal dialog.  This is a 
  400. regression from JDK 1.1.1.  This bug has been fixed in JDK 1.1.4 
  401. [Bug 4068651]
  402.  
  403. ______________
  404. AWT CURSOR BUG - In JDK 1.1.3, Frame.setCursor sometimes didn't update 
  405. the cursor until the user moved the mouse. This bug has been fixed 
  406. in JDK 1.1.4.  [Bug 4040388]
  407.  
  408. ___________________
  409. AWT KEYBOARD EVENTS - Caps lock and Shift keyboard events did not 
  410. work properly on Win32 versions of JDK 1.1.3. This problem has been 
  411. fixed in JDK 1.1.4. [Bug 4067542]
  412.  
  413. _________________________
  414. AWT WINDOW ACTIVATION BUG - In JDK 1.1.3, invisible windows could not 
  415. be activated, which caused applets to hang. This bug has been fixed 
  416. in JDK 1.1.4.  [Bug 4068536]
  417.  
  418. _____________________
  419. AWT COLOR SUPPORT BUG - Previous versions of JDK 1.1 did not correctly 
  420. handle 8-bit TrueColor. This problem has been corrected in JDK 1.1.4.
  421. [Bug 4061285]
  422.  
  423. _______
  424. JNI BUG - In JDK 1.1.4, the JNI_GetDefaultJavaVMInitArgs function has 
  425. been corrected to properly set the default system class path. In 
  426. previous versions of the JDK, the default system class path was set to 
  427. NULL.
  428.  
  429. ________________
  430. LOCALIZATION BUG - In the zh_TW.BIG5 locale, users could not input 
  431. Chinese characters into the text area. This problem has been fixed 
  432. in JDK 1.1.4.  [Bug 4053637]
  433.  
  434. ____________________
  435. java INTERPRETER BUG - In previous releases of JDK 1.1, the java 
  436. interpreter would allow the class file at /a/b/c.class to be invoked 
  437. from within the /a/b directory by the command "java c", even if the 
  438. class c was in package a.b.*. This behavior is incorrect and has been 
  439. fixed in JDK 1.1.4. In JDK 1.1.4, the fully qualified class name must 
  440. be specified. For example, to invoke the class a.b.c at /a/b/c.class, 
  441. the command "java a.b.c" could be issued from the parent directory of 
  442. directory /a.
  443.  
  444. _________________
  445. jdb DEBUGGER BUGS - Several Java debugger problems are fixed in JDK 
  446. 1.1.4. In previous JDKs, the debugger could not print a static member 
  447. whose type was a string. Setting a breakpoint in a native method would 
  448. cause the debugger to crash. These debugger problems have been fixed 
  449. in JDK 1.1.4.  [Bugs 4064129, 4062582]
  450.  
  451.  
  452. =======================================================================
  453. Changes from JDK 1.1.2 to JDK 1.1.3
  454. -----------------------------------------------------------------------
  455.  
  456. JDK 1.1.3 is a maintenance release to correct a localization problem in 
  457. the Solaris JDK 1.1.2. The following list summarizes changes in 
  458. JDK 1.1.3.
  459. ______________
  460. VERSION NUMBER - The version number for this release is "JDK1.1.3".
  461.  
  462. ________________
  463. LOCALIZATION BUG - In Solaris versions of JDK 1.1.2, the mechanism 
  464. for loading the ByteToCharConverter classes for non-8859_1 encodings 
  465. was broken. Characters in text areas of windows did not display 
  466. properly for non-English-language locales and non-Western European 
  467. locales. This problem did not exist in JDK 1.1.1. This bug has been 
  468. fixed in JDK 1.1.3.  [Bugs 4049223, 4055084]
  469.  
  470. ___________________________
  471. VERIFIER IMPLEMENTATION BUG - A bug in the JDK 1.1.2 verifier would 
  472. allow a type-unsafe applet to search and locate strings stored in the 
  473. browser's address space. This bug is not known to be present in 
  474. JDK 1.0.x. This bug has been fixed in JDK 1.1.3. [Bug 4059597]
  475.  
  476. ______________ 
  477. JAVA BEANS BUG - The method java.beans.BeanInfo.getMethodDescriptors() 
  478. did not return MethodDescriptors for all externally visible methods 
  479. in some situations. getMethodDescriptors() did not report methods 
  480. having no arguments when those methods were defined later in a class 
  481. than similarly named methods having arguments. This problem did not 
  482. exist in JDK 1.1.1. This bug has been fixed in JDK 1.1.3. [Bug 4056837]
  483.  
  484. _______________
  485. AWT REPAINT BUG - Synchronization problems with graphics in the 
  486. Win32 version of JDK 1.1.2 would cause graphics deadlocks or 
  487. crashes of the Java virtual machine in some situations. This problem 
  488. did not exist in JDK 1.1.1. This bug has been fixed in JDK 1.1.3.
  489. [Bugs 4049421, 4051303]
  490.  
  491. ________________
  492. java_g -prof BUG - The profiling option of the Java interpreter 
  493. did not work in the Win32 version of JDK 1.1.2. Using a command
  494. such as    C:\> java_g -prof MyClass     would cause the Java 
  495. virtual machine to crash. This problem did not exist in JDK 1.1.1. 
  496. This bug has been fixed in JDK 1.1.3. [Bug 4056944]
  497.  
  498. _______________________
  499. AWT FONTMETRICS SPEEDUP - Improvements have been made to AWT font 
  500. metrics in JDK 1.1.3, resulting in significant speedups for programs 
  501. such as HotJava that rely heavily on text rendering. 
  502. [Bug 4046795]
  503.  
  504. _________________
  505. AWT COMPONENT BUG - In the Windows version of JDK 1.1.2, a race 
  506. condition sometimes caused the HotJava browser to crash when disposing 
  507. components that were in the process of being shown. This bug has 
  508. been fixed in JDK 1.1.3.  [Bug 4051487]
  509.  
  510. ________________
  511. AWT GRAPHICS BUG - In the Windows version of JDK 1.1.2, multi-
  512. threaded access to Graphics objects sometimes resulted in dangling 
  513. pointers due to a race condition in awt_Graphics.cpp. This bug has 
  514. been fixed in JDK 1.1.3. [Bug 4049421]
  515.  
  516. ________________
  517. INPUT STREAM BUG - An InputStreamReader using the UTF8 encoding 
  518. produced an erroneous character stream with missing characters. 
  519. This bug has been fixed in JDK 1.1.3  [Bug 4059684]
  520.  
  521.  
  522. =======================================================================
  523. Changes from JDK 1.1.1 to JDK 1.1.2
  524. -----------------------------------------------------------------------
  525.  
  526. JDK 1.1.2 is a maintenance release. The following is a list of
  527. important bug fixes and other changes in JDK 1.1.2.
  528. ______________
  529. VERSION NUMBER - The version number for this release is "JDK1.1.2".
  530.  
  531. ____________
  532. VERIFIER BUG - The JDK 1.1.1 bytecode verifier did not check to 
  533. determine whether the number of arguments passed into a method is less 
  534. than the amount of memory allocated to local variables for that 
  535. method. There was no known security attack based on this bug. This bug 
  536. has been corrected in JDK 1.1.2.
  537.  
  538. ___________
  539. SIGNING BUG - In JDK 1.1.1, digitally signed code could be 
  540. manipulated to impersonate another digital signature from the list of 
  541. signers that are recorded in the Java runtime. This bug has been 
  542. fixed in JDK 1.1.2. [Bug 4048143]
  543.  
  544. _______
  545. DSA BUG - In JDK 1.1.1, the same default seed was used for every 
  546. invocation of DSA. This bug has been fixed in JDK 1.1.2. 
  547. [Bug 4050406]
  548.  
  549. ________________
  550. AWT MENU BUG FIX - Trying to add a pull-right cascade menu to a 
  551. PopupMenu in JDK 1.1.1 led to an exception. This problem did not 
  552. exist in JDK 1.1. This bug has been corrected in JDK 1.1.2.
  553. [Bug 4039089]
  554.  
  555. _________________________________
  556. AWT LIGHTWEIGHT COMPONENT BUG FIX - Mouse tracking events for 
  557. lightweight components were not being delivered in some situations. 
  558. This bug has been fixed in JDK 1.1.2.  [Bug 4038897]
  559.  
  560. ___________________
  561. AWT REPAINT BUG FIX - Some components were not being repainted 
  562. properly in some situations in JDK 1.1.1. This problem did not 
  563. exist in JDK 1.1. This bug has been fixed in JDK 1.1.2.
  564. [Bug 4040638]
  565.  
  566. __________________
  567. AWT DIALOG BUG FIX - Closing nested modal dialogs out of order would 
  568. cause parent to remain disabled in some cases. This bug has been fixed 
  569. in JDK1.1.2.  [Bug 4045610]
  570.  
  571. _________________
  572. AWT FOCUS BUG FIX - Setting default focus caused applets to hang in 
  573. some situations. This problem did not exist in JDK 1.1. This bug 
  574. has been fixed in JDK 1.1.2.  [Bug 4038896]
  575.  
  576. ____________________
  577. APPLETVIEWER BUG FIX - Trying to save an applet from the Appletviewer 
  578. led to an exception. This bug has been fixed in JDK 1.1.2.
  579. [Bug 4036537]
  580.  
  581. ________________
  582. DEBUGGER BUG FIX - The debugger "dump" command converted double 
  583. values to float values before displaying them. This bug has been fixed 
  584. in JDK 1.1.2.  [Bug 4046775]
  585.  
  586. _______________
  587. JAVADOC BUG FIX - The javadoc html output for interfaces repeated 
  588. the word "interface" in the signature. This bug has been fixed in 
  589. JDK 1.1.2.  [Bug 4041579]
  590.  
  591. __________________________
  592. JNI INVOCATION API CHANGES - To better support the JRE, the 
  593. Invocation API is extended in JDK 1.1.2 in a few minor ways. 
  594. The changes do not break any existing code. The JNI Native 
  595. Method Interface has not been changed. 
  596.  
  597. 1. The reserved0 field in the JDK1_1InitArgs structure has been
  598. renamed to "version." The JDK1_1InitArgs structure holds the
  599. initialization arguments to JNI_CreateJavaVM. Callers of 
  600. JNI_CreateJavaVM must set the version field to 0x00010001. 
  601. JNI_GetDefaultJavaVMInitArgs has been changed to return a "jint" 
  602. indicating whether the requested version is supported.
  603.  
  604. 2. The reserved1 field in the JDK1_1InitArgs structure has been
  605. renamed to "properties." This is a NULL-terminated array of 
  606. strings. Each string has the format:
  607.  
  608.             name=value
  609.  
  610. indicating a system property. (This facility corresponds to the -D
  611. option in the java command line.)
  612.  
  613. 3. In JDK 1.1.1, the thread calling DestroyJavaVM must be the only
  614. user thread in the VM. JDK 1.1.2 has lifted this restriction. If
  615. DestroyJavaVM is called when there is more than one user thread,
  616. the VM waits until the current thread is the only user thread, and
  617. then tries to destroy itself.
  618.  
  619. _________________________
  620. NEW jre COMMAND-LINE TOOL - The jre command-line tool is similar to 
  621. the java command-line tool, but is intended primarily for end users 
  622. who do not require the development-related options available with 
  623. the java tool. For more information on the jre tool, see 
  624. http://java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/jre.html
  625. or http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/jre.html. 
  626. Source code for the jre tool can be found in the Windows JDK 1.1.2 
  627. directory tree in the jdk1.1.2\demo\jre\win32 folder. In the 
  628. Solaris JDK 1.1.2, jre source files can be found in the 
  629. jdk1.1.2/demo/jre/solaris directory.
  630.  
  631.  
  632. =======================================================================
  633. Changes from JDK 1.1_Final to JDK 1.1.1
  634. -----------------------------------------------------------------------
  635.  
  636. The following changes and bug fixes are in the JDK 1.1.1 final release.
  637. This is a maintenance release.
  638. ______________
  639. VERSION NUMBER - The version number for this release is "JDK1.1.1". 
  640.  
  641. _________
  642. BUG FIXES - This version contains the bug fixes listed at the 
  643.     web page mentioned above. 
  644.  
  645. ____________
  646. UTIL BUG FIX - Removed getMenu and getMenuBar methods from 
  647.     util.ResourceBundle class. [Bug 4036076]
  648.  
  649.     This bug fix is mentioned here because it fixes an API bug
  650.     in JDK 1.1.
  651.  
  652.     These two "convenience" methods were part of the beta release
  653.     and were mistakenly left in the final JDK 1.1 after we
  654.     discovered the design weakness they presented and decided to
  655.     remove them.  It is a bug that they were included in the 1.1
  656.     release, and you should not call these methods.   We have 
  657.     removed them in 1.1.1.  Being convenience methods, they are not 
  658.     essential, and alternate coding is simple.   
  659.  
  660.     To be more specific, the ResourceBundle class in JDK 1.1 
  661.     included the two methods:
  662.  
  663.     public final Menu getMenu(String key) 
  664.         throws MissingResourceException {
  665.              return (Menu) getObject(key);
  666.          }
  667.  
  668.      public final MenuBar getMenuBar(String key) 
  669.         throws MissingResourceException {
  670.              return (MenuBar) getObject(key);
  671.      }
  672.  
  673.     These "convenience" methods saved the user from having to
  674.     explicitly cast objects in a ResourceBundle that happened to 
  675.     be of type Menu or MenuBar, such as:
  676.     
  677.        (Menu)rb.getObject(key)
  678.     
  679.     The side effect was that by returning types Menu and MenuBar, this 
  680.     class referred to the awt package.  ResourceBundle is a relatively 
  681.     low level piece of the core however while AWT is a relatively high 
  682.     level piece. This dependency caused a number of problems.  Most 
  683.     notably it did not allow a Java runtime environment to be created 
  684.     that omitted the AWT package (such as in a server).
  685.     
  686.     Removing this dependency on AWT required removing these APIs 
  687.     completely from ResourceBundle.  This change, of course, breaks 
  688.     code that calls these methods.  The upside is that these two APIs 
  689.     were of very little marginal value.  They simply saved the user 
  690.     the effort of typing an explicit cast. Furthermore, since these
  691.     two methods were new at 1.1, they have not been available for
  692.     very long. 
  693.  
  694. _____________________
  695. AWT COMPONENT BUG FIX - Changed the field java.awt.Component.locale
  696.     from protected to private.  
  697.  
  698.     The locale field is accessible through getLocale() and 
  699.     setLocale() methods, and all code should be using those.  
  700.     This change is necessary to support future development of 
  701.     the lightweight framework.
  702.  
  703. ________________________
  704. AWT DATATRANSFER BUG FIX - Corrected the MIME type for DataFlavor.
  705.     [Bug 4037854]
  706.  
  707.     In JDK 1.1, java.awt.datatransfer.DataFlavor used the wrong MIME
  708.     type.  DataFlavor claimed that the MIME type for a java 
  709.     serialized object was: 
  710.  
  711.        application/x-javaserializedobject 
  712.  
  713.     This name is inconsistent with other existing names and common
  714.     conventions. The name has been corrected by adding hypens to it, 
  715.     as follows:
  716.  
  717.        application/x-java-serialized-object 
  718.  
  719.     This makes it consistent with: 
  720.  
  721.        application/java-vm 
  722.        application/x-java-vm 
  723.        application/x-java-archive 
  724.  
  725. ____________
  726. FONT CHANGES - Times, Helvetica, and Courier are now mapped to
  727.     Latin1 characters.
  728.  
  729.     Times, Helvetica, and Courier fonts are no longer mapped to 
  730.     non-Latin1 classes of fonts, such as Symbol or ZapfDingabats.
  731.     These three fonts are now mapped to Latin1 characters, just like
  732.     they were in version 1.0.
  733.  
  734.     If you want to have non-Latin1 characters, you must map fonts
  735.     such as Symbol and ZapfDingabats to the Java virtual fonts.  These
  736.     virtual font classes are Serif, Sans-serif, Monospaced, Dialog, 
  737.     and DialogInput.
  738.     
  739.  
  740. ===================================================================
  741. Changes from JDK 1.1beta3 to JDK 1.1_Final
  742. -------------------------------------------------------------------
  743.  
  744. The following changes and bug fixes are in the JDK 1.1 final release.
  745.  
  746. ______________
  747. VERSION NUMBER - The version number for this release is "JDK1.1_Final". 
  748.     Throughout the documentation we call it simply "JDK1.1"
  749.  
  750. ____________
  751. TEXT CHANGES - Extensive surface changes to Text package
  752.  
  753.     The following extensive changes in the Text package are the
  754.     result of a design review recently carried out to
  755.     simplify, rationalize and properly abstract the 
  756.     internationalization API.  We realized this would 
  757.     make a significant improvement in learning and using 
  758.     internationalization in Java.  
  759.  
  760.     The changes involve mostly surface changes, such as 
  761.     renaming and moving API, and changing the order of arguments,
  762.     to better conform with conventions established with the rest
  763.     of Java.
  764.  
  765. ____________
  766. TEXT CHANGES - CharacterIterator
  767.  
  768.     Removed getText method. CharacterIterators are intended to allow 
  769. character
  770.     at a time access to text without exposing how the text is actually 
  771. stored.
  772.     It is expected that some CharacterIterators will operate on text 
  773. that can
  774.     not easily or efficiently be stored as a String. Accessing the text 
  775. as a
  776.     whole should be the responsibility of the text object.
  777.  
  778.     Rename startIndex to getBeginIndex and rename endIndex to
  779.     getEndIndex. This is to follow established naming patterns for 
  780. getters and
  781.     setters as well as java.lang.String's convention for identifying 
  782. ranges in
  783.     text.
  784.  
  785. ____________
  786. TEXT CHANGES - ChoiceFormat
  787.  
  788.     Changed the constructor to take an array of Strings rather than an 
  789. array
  790.     of Objects.  String were the only type that made sense in this 
  791. context.
  792.  
  793.     Changed the setChoices method to take an array of Strings rather 
  794. than an
  795.     array of Objects.  String were the only type that made sense in 
  796. this
  797.     context.  
  798.  
  799.     Added applyPattern and toPattern methods similar to the methods on 
  800. other 
  801.     Format classes.
  802.  
  803.     Changed the format methods to take a FieldPosition rather than a
  804.     FormatStatus argument. See the change description for FormatStatus.
  805.     
  806.     Changed the parse method to take a ParsePosition rather than a 
  807. ParseStatus
  808.     argument. See the change description for ParseStatus.
  809.     
  810.     Added clone, hashCode and equals methods.  These are standard 
  811. overrides
  812.     and do not change the semantics.
  813.  
  814. ____________
  815. TEXT CHANGES - Collation
  816.  
  817.     Renamed class "Collator".  It was not clear from the old name 
  818. whether this
  819.     class actually did collation or simply represented a set of 
  820. collation
  821.     rules.  The new name makes it clear that the class performs string
  822.     comparisons.
  823.     
  824.     Removed the constants LESS, EQUAL and GREATER. Changed the compare 
  825. methods
  826.     to return the int value -1, 0 or 1 instead of LESS, EQUAL or 
  827. GREATER. This
  828.     follows the pattern used by the java.lang.String.compareTo method.
  829.     
  830.     Removed the greater and greaterOrEqual methods.  The same 
  831. information is
  832.     provided by the compare method.  Having only a compare and and 
  833. equals 
  834.     method mimics the comparison API provided by java.lang.String.
  835.     
  836.     Removed the compare(String, int, int, String, int, int) version of 
  837. the
  838.     compare method and the getSortKey(String, int, int) version of the
  839.     getSortKey method. A recent change to String.substring makes the 
  840. substring
  841.     operation efficient. Users can use String.substring to specify a 
  842. substring
  843.     rather than requiring methods to provide substring variants. 
  844. Slimming the
  845.     API makes it easier to learn.
  846.     
  847.     Changed the type of public constants from byte to int.  Changed the
  848.     getStrength and getDecomposition methods to return int instead of 
  849. byte.
  850.     Changed the setStrength and setDecomposition methods to accept int
  851.     arguments instead of byte.  Although the byte type provides a small 
  852. amount
  853.     of type safety, using ints for constants is more in keeping with 
  854. the rest
  855.     of the JDK.  The affected constants are:
  856.     
  857.      byte PRIMARY = 0;                 ==>    int PRIMARY = 0;                
  858.      byte SECONDARY = 1;               ==>    int SECONDARY = 1;              
  859.      byte TERTIARY = 2;                ==>    int TERTIARY = 2;               
  860.      byte IDENTICAL = 3;               ==>    int IDENTICAL = 3;              
  861.      byte NO_DECOMPOSITION = 0;        ==>    int NO_DECOMPOSITION = 0;       
  862.      byte CANONICAL_DECOMPOSITION = 1; ==>    int 
  863. CANONICAL_DECOMPOSITION = 1;
  864.      byte FULL_DECOMPOSITION = 2;      ==>    int FULL_DECOMPOSITION = 
  865. 2;     
  866.     
  867.     Removed the getDisplayName methods.  These returned the same result 
  868. as
  869.     the corresponding Locale.getDisplayName method calls.  Until we 
  870. have more
  871.     useful data, its better not to have these methods in the API.
  872.     
  873.     Provided a concrete equals method.  This allows sub-classes to 
  874. correctly
  875.     implement the equals method.
  876.     
  877.     Renamed getSortKey method to getCollationKey.  See the change 
  878. description
  879.     for getSortKey.
  880.     
  881.     Renamed getDefault methods to getInstance.  This follows new naming 
  882. pattern
  883.     for factory methods.
  884.  
  885. ____________
  886. TEXT CHANGES - CollatedString
  887.  
  888.     Removed this class.  Its purpose was to associate a String with its
  889.     CollationKey. CollationKey has been changed retain a reference to 
  890. the 
  891.     String it was generated from.  This allows us to reduce the size of 
  892. the 
  893.     API.
  894.  
  895. ____________
  896. TEXT CHANGES - CollationElementIterator
  897.  
  898.     Removed the public constructor. CollationElementIterators are 
  899. created by
  900.     RuleBasedCollator objects.  This was expressed by handing a
  901.     RuleBasedCollator object to the constructor.  This connection is 
  902. more
  903.     obvious if the CollationElementIterator can only be created by a 
  904. factory
  905.     method on RuleBasedCollator.
  906.  
  907.     Made the values returned by the next method directly comparable.  
  908. This is
  909.     not an API change but a semantic change for the next method.
  910.     
  911. ____________
  912. TEXT CHANGES - DateFormat
  913.  
  914.     Made the constructor protected.  DateFormat is an abstract class so 
  915. it
  916.     doesn't need a public constructor.
  917.     
  918.     Removed the getDisplayName methods.  These returned the same result 
  919. as
  920.     the corresponding Locale.getDisplayName method calls.  Until we 
  921. have more
  922.     useful data, its better not to have these methods in the API.
  923.     
  924.     Added a style called MEDIUM that does what DEFAULT does now. For 
  925. this
  926.     release, MEDIUM and DEFAULT have the same effect.  In future, the 
  927. meaning 
  928.     of DEFAULT will be determined from the locale data. This is a more 
  929.     logical organization of the style choices.
  930.     
  931.     Changed the format methods to take a FieldPosition rather than a
  932.     FormatStatus argument. See the change description for FormatStatus.
  933.     
  934.     Changed the parse and parseObject methods to take a ParsePosition 
  935. rather
  936.     than a ParseStatus argument. See the change description for 
  937. ParseStatus.
  938.     
  939.     Renamed the getTimeFormat methods to getTimeInstance.  Renamed the
  940.     getDateFormat methods to getDateInstance.  Renamed the 
  941. getDateTimeFormat
  942.     methods to getDateTimeInstance.  This follows new naming pattern
  943.     for factory methods.
  944.     
  945.     Added a getInstance() factory method that does the same thing as
  946.     getDateTimeFormat(SHORT,SHORT) previously did. This follows the 
  947. pattern 
  948.     for factories which provides for a getInstance() that returns a 
  949. default 
  950.     value to be always available.
  951.     
  952.     Renamed getValidationMode to isLenient.  Renamed setValidationMode 
  953. to
  954.     setLenient. These names are more descriptive.
  955.     
  956.     Change the type of public constants from byte to int.  Although the 
  957. byte
  958.     type provides a small amount of type safety, using ints for 
  959. constants is
  960.     more in keeping with the rest of the JDK. Also rename constants to 
  961. follow
  962.     the naming convention uses by JDK.  The results are:
  963.     
  964.      byte ERA_FIELD = 0;               ==> int ERA_FIELD = 0;
  965.      byte YEAR_FIELD = 1;              ==> int YEAR_FIELD = 1;
  966.      byte MONTH_FIELD = 2;             ==> int MONTH_FIELD = 2;
  967.      byte DATE_FIELD = 3;              ==> int DATE_FIELD = 3;
  968.      byte HOUROFDAY1_FIELD = 4;        ==> int HOUR_OF_DAY1_FIELD = 4;
  969.      byte HOUROFDAY0_FIELD = 5;        ==> int HOUR_OF_DAY0_FIELD = 5;
  970.      byte MINUTE_FIELD = 6;            ==> int MINUTE_FIELD = 6;
  971.      byte SECOND_FIELD = 7;            ==> int SECOND_FIELD = 7;
  972.      byte MILLISECOND_FIELD = 8;       ==> int MILLISECOND_FIELD = 8;
  973.      byte DAYOFWEEK_FIELD = 9;         ==> int DAY_OF_WEEK_FIELD = 9;
  974.      byte DAYOFYEAR_FIELD = 10;        ==> int DAY_OF_YEAR_FIELD = 10;
  975.      byte DAYOFWEEKINMONTH_FIELD = 11; ==> int 
  976. DAY_OF_WEEK_IN_MONTH_FIELD = 11;
  977.      byte WEEKOFYEAR_FIELD = 12;       ==> int WEEK_OF_YEAR_FIELD = 12;
  978.      byte WEEKOFMONTH_FIELD = 13;      ==> int WEEK_OF_MONTH_FIELD = 
  979. 13;
  980.      byte AMPM_FIELD = 14;             ==> int AM_PM_FIELD = 14;
  981.      byte HOUR1_FIELD = 15;            ==> int HOUR1_FIELD = 15;
  982.      byte HOUR0_FIELD = 16;            ==> int HOUR0_FIELD = 16;
  983.      byte TIMEZONE_FIELD = 17;         ==> int TIMEZONE_FIELD = 17;
  984.     
  985. ____________
  986. TEXT CHANGES - DateFormatData
  987.  
  988.     Renamed class to DateFormatSymbols.  This makes its purpose as a 
  989. set of
  990.     strings and symbols to be used in formatting clearer.
  991.     
  992.     Removed the millisPerHour protected field.  This was not an 
  993. appropriate
  994.     field in a collection of formatting symbols.
  995.     
  996.     Renamed getAmpms to getAmPmStrings.  Renamed setAmpms to 
  997. setAmPmStrings. 
  998.     The new names follow the capitalization standard and are clearer.
  999.     
  1000.     Removed methods useLocalizedPattern and setPatternLocalized.  This
  1001.     functionality can be obtained through the toLocalizedPattern and
  1002.     applyLocalizedPattern methods of SimpleDateFormat. These methods 
  1003. were not
  1004.     appropriate in a collection of formatting symbols.
  1005.     
  1006. ____________
  1007. TEXT CHANGES - DecimalFormat
  1008.  
  1009.     Renamed getThousandsInterval and setThousandsInterval methods to
  1010.     getGroupingSize and setGroupingSize.  The new names are clearer.
  1011.     
  1012.     Renamed getFactor and setFactor methods to getMultiplier and 
  1013. setMultiplier.
  1014.     The new names are clearer.
  1015.     
  1016.     Changed the constructor that takes a NumberFormatData to use a
  1017.     DecimalFormatSymbols object instead. See the change description for
  1018.     NumberFormatData. 
  1019.     
  1020.     Added a constructor that takes just a String and figures out the 
  1021. correct
  1022.     DecimalFormatSymbols for the default locale.  This fills in the 
  1023. telescope
  1024.     pattern for constructors.
  1025.     
  1026.     Renamed getPattern method to toPattern. Also removed the boolean 
  1027. argument
  1028.     and instead added a toLocalizedPattern method. The new name better
  1029.     reflects the fact that there is no "pattern" property, but rather a
  1030.     pattern string is constructed that matches the current state of the
  1031.     DecimalFormat object. Splitting the method into two allows many 
  1032. users to
  1033.     ignore the existence of toLocalizedPattern.
  1034.     
  1035.     Renamed setPattern method to applyPattern. Also removed the boolean 
  1036.     argument and instead added an applyLocalizedPattern method. The new 
  1037.     name better reflects the fact that there is no "pattern" property, 
  1038.     but rather a pattern string is used to set the state of the 
  1039. DecimalFormat 
  1040.     object. Splitting the method into two allows many users to ignore 
  1041. the 
  1042.     existence of applyLocalizedPattern.
  1043.     
  1044.     Removed the "*" and "_" characters from the pattern syntax.  This 
  1045. is not
  1046.     strictly an api change but it is a semantic change.  These 
  1047. characters were
  1048.     of limited use the way they were implemented.
  1049.     
  1050.     Changed the format methods to take a FieldPosition rather than a
  1051.     FormatStatus argument. See the change description for FormatStatus.
  1052.     
  1053.     Changed the parse method to take a ParsePosition rather than a
  1054.     ParseStatus argument. See the change description for ParseStatus.
  1055.     
  1056.     Renamed getNumberFormatData to getDecimalFormatSymbols and changed 
  1057. its
  1058.     return type to DecimalFormatSymbols.  Renamed setNumberFormatData 
  1059. to
  1060.     setDecimalFormatSymbols and changed its argument type to
  1061.     DecimalFormatSymbols.  See the change description for 
  1062. NumberFormatData.
  1063.     
  1064. ____________
  1065. TEXT CHANGES - Format
  1066.     
  1067.     Changed the format method to take a FieldPosition rather than a 
  1068.     FormatStatus argument. See the change description for FormatStatus.
  1069.     
  1070.     Changed the parseObject method to take a ParsePosition rather than 
  1071. a
  1072.     ParseStatus argument. See the change description for ParseStatus.
  1073.  
  1074. ____________
  1075. TEXT CHANGES - FormatException
  1076.  
  1077.     Renamed class to ParseException.  This better reflects its purpose.
  1078.     
  1079.     Removed the no argument constructor.  This constructor was not 
  1080. useful.
  1081.  
  1082. ____________
  1083. TEXT CHANGES - FormatStatus
  1084.  
  1085.     Renamed class to FieldPosition.  This better reflects its purpose 
  1086. as an
  1087.     object which describes where sub-fields are located in a formatted 
  1088. string.
  1089.     
  1090.     Replaced public integer fields with getter methods.  Adjusted names 
  1091. to
  1092.     match pattern for indicating ranges in text.  The result:
  1093.     
  1094.      int alignField   ==> int getField()
  1095.      int alignStart   ==> int getBeginIndex()
  1096.      int alignEnd     ==> int getEndIndex()
  1097.     
  1098.     Replaced no argument constructor with a constructor that sets the 
  1099. field.
  1100.     A field value must always be set so this prevents invalid objects.  
  1101.     It is also more convenient than doing it in two steps.
  1102.     
  1103. ____________
  1104. TEXT CHANGES - MessageFormat
  1105.  
  1106.     Redesigned the syntax for message patterns to allow inlining of 
  1107. other
  1108.     pattern strings, such as date patterns, number patterns, choice 
  1109. patterns
  1110.     etc. This is not itself an API change but is a big semantic 
  1111. difference.
  1112.     This change allows complete message formats to be created in fewer 
  1113. steps.
  1114.  
  1115.     Removed the constructor that took a String and a Format array.  
  1116. This was
  1117.     not needed with the new inline pattern syntax.
  1118.  
  1119.     Added a setFormat method which allows a single format to be set at 
  1120. a time
  1121.     rather than requiring all formats to be specified like the 
  1122. setFormats
  1123.     method. This is more convenient given the inline pattern syntax.
  1124.  
  1125.     Removed the format method that took a String, a Format array and an 
  1126. Object
  1127.     array.  It was not necessary with the new inline pattern syntax.
  1128.  
  1129.     Changed the parse method that takes a single String argument to 
  1130. return an
  1131.     array of Objects rather than a single Object.  This makes more 
  1132. sense given
  1133.     the fact that a message may have many objects embedded in it.
  1134.     
  1135.     Changed the format methods to take a FieldPosition rather than a
  1136.     FormatStatus argument. See the change description for FormatStatus.
  1137.     
  1138.     Changed the parse method to take a ParsePosition rather than a 
  1139. ParseStatus
  1140.     argument. See the change description for ParseStatus.
  1141.     
  1142.     Renamed getPattern method to toPattern. The new name better 
  1143. reflects the
  1144.     fact that there is no "pattern" property. Rather a pattern string 
  1145. is
  1146.     constructed that matches the current state of the MessageFormat 
  1147. object.
  1148.     
  1149.     Renamed setPattern method to applyPattern. The new name better 
  1150. reflects
  1151.     the fact that there is no "pattern" property. Rather a pattern 
  1152. string is
  1153.     used to set the state of the MessageFormat object.
  1154.  
  1155.     Added setLocale and getLocale methods.
  1156.  
  1157. ____________
  1158. TEXT CHANGES - NumberFormat
  1159.  
  1160.     Renamed getDefaultCurrency to getCurrencyInstance.  Renamed
  1161.     getDefaultPercent to getPercentInstance.  Added a getNumberInstance
  1162.     factory.  Rename getDefault to getInstance.  This follows the 
  1163. naming
  1164.     pattern for factories.
  1165.     
  1166.     Removed getCurrencySymbol and getIntlCurrencySymbol methods. These 
  1167. will be
  1168.     added to a more appropriate class in a future release.
  1169.     
  1170.     In the methods called 
  1171. {get|set}{Minimum|Maximum}{Integer|Decimal}Count,
  1172.     rename the word Count to Digits and the word Decimal to Fraction.  
  1173. These
  1174.     names are clearer.
  1175.     
  1176.     Remove the methods isDecimalUsedWithInteger and
  1177.     setDecimalUsedWithInteger. These methods are now found in 
  1178. DecimalFormat
  1179.     under the names isDecimalSeparatorAlwaysShown
  1180.     setDecimalSeparatorAlwaysShown.
  1181.     
  1182.     Renamed setIntegerOnly to setParseIntegerOnly. Renamed 
  1183. isIntegerOnly to
  1184.     isParseIntegerOnly.
  1185.     
  1186.     Renamed {is|set}ThousandsUsed to {is|set}GroupingUsed.
  1187.     
  1188.     Removed the getDisplayName methods.  These returned the same result 
  1189. as
  1190.     the corresponding Locale.getDisplayName method calls.  Until we 
  1191. have more
  1192.     useful data, its better not to have these methods in the API.
  1193.     
  1194.     Renamed DECIMAL_FIELD to FRACTION_FIELD. Also changed its type from 
  1195. byte
  1196.     to int. This name is more general. Use of ints as constants is 
  1197. standard
  1198.     practice.
  1199.     
  1200.     Removed NUMERATOR_FIELD, DENOMINATOR_FIELD and EXPONENT_FIELD. This
  1201.     functionality was not supported in this release.
  1202.  
  1203. ____________
  1204. TEXT CHANGES - NumberFormatData
  1205.  
  1206.     Renamed class DecimalFormatSymbols. This makes its purpose as a set 
  1207. of
  1208.     strings and symbols to be used in formatting clearer.
  1209.     
  1210.     Added a default constructor which constructs an object suitable for 
  1211. the
  1212.     default locale.  Added a constructor which takes a locale.  These 
  1213. follow 
  1214.     the pattern set by DateFormatSymbols.
  1215.     
  1216.     Removed starDigit, spaceDigit and exponential fields.  This 
  1217. functionality 
  1218.     is not being supported by DecimalFormat.
  1219.     
  1220.     Changed public fields to getter/setter methods.  Adjusted the names 
  1221. of the
  1222.     methods for clarity.  The results are:
  1223.     
  1224.      char zeroDigit;         ==> getZeroDigit(), setZeroDigit()        
  1225.      char thousandsSign;     ==> getGroupingSeparator(), 
  1226. setGroupingSeparator()
  1227.      char decimalSign;       ==> getDecimalSeparator(), 
  1228. setDecimalSeparator()
  1229.      char millePercent;      ==> getPerMill(), setPerMill()               
  1230.      char percent;           ==> getPercent(), setPercent()               
  1231.      char digit;             ==> getDigit(), setDigit()               
  1232.      char separator;         ==> getPatternSeparator(), 
  1233. setPatternSeparator() 
  1234.      java.lang.String infinity; ==> getInfinity(), setInfinity()    
  1235.      java.lang.String nan;   ==> getNaN(), setNaN()
  1236.      char minusSign;         ==> getMinusSign(), setMinusSign()    
  1237.     
  1238.     Removed the static final char fields.  These were not appropriate 
  1239. for a
  1240.     collection of locale specific number formatting fields.  They were 
  1241. also 
  1242.     of little use outside the implementation of DecimalFormat. The 
  1243. removed 
  1244.     fields are:
  1245.     
  1246.      static final char patternZeroDigit = 48;
  1247.      static final char patternThousandsSign =
  1248.      static final char patternDecimalSign = 4
  1249.      static final char patternMillePercent = 
  1250.      static final char patternPercent = 37;  
  1251.      static final char patternDigit = 35;    
  1252.      static final char patternStarDigit = 42;
  1253.      static final char patternSpaceDigit = 95
  1254.      static final char patternSeparator = 59;
  1255.  
  1256. ____________
  1257. TEXT CHANGES - ParseStatus
  1258.  
  1259.     Renamed class ParsePosition.  This better reflects its purpose as 
  1260. an object
  1261.     which shows where parsing starts and stops.
  1262.     
  1263.     Removed no argument constructor. This was redundant and of no real
  1264.     convenience.
  1265.     
  1266.     Changed public field startAt to a getter/setter method pair.  Also
  1267.     adjusted names of the methods to suit the naming pattern for 
  1268. indicating
  1269.     characters in a String.  The results:
  1270.     
  1271.       startAt   ==> getIndex(), setIndex()
  1272.  
  1273. ____________
  1274. TEXT CHANGES - SimpleDateFormat
  1275.  
  1276.     Changed the format method to take a FieldPosition rather than a 
  1277.     FormatStatus argument. See the change description for FormatStatus.
  1278.     
  1279.     Changed the parse method to take a ParsePosition rather than a 
  1280. ParseStatus
  1281.     argument. See the change description for ParseStatus.
  1282.     
  1283.     Changed the constructor which took a DateFormatData object to use a
  1284.     DateFormatSymbols object instead.  See the change description for
  1285.     DateFormatData.
  1286.     
  1287.     Renamed getDateFormatData and setDateFormatData to 
  1288. getDateFormatSymbols 
  1289.     and setDateFormatSymbols. See the change description for 
  1290. DateFormatData.
  1291.     
  1292.     Renamed getPattern method to toPattern. Also removed the boolean 
  1293. argument 
  1294.     and instead added a toLocalizedPattern method. The new name better 
  1295.     reflects the fact that there is no "pattern" property, but rather a 
  1296.     pattern string is constructed that matches the current state of the 
  1297.     DecimalFormat object. Splitting the method into two allows many 
  1298. users 
  1299.     to ignore the existence of toLocalizedPattern.
  1300.     
  1301.     Renamed setPattern method to applyPattern. Also removed the boolean 
  1302.     argument and instead added an applyLocalizedPattern method. The new 
  1303.     name better reflects the fact that there is no "pattern" property, 
  1304. but 
  1305.     rather a pattern string is used to set the state of the 
  1306. DecimalFormat 
  1307.     object. Splitting the method into two allows many users to ignore 
  1308. the 
  1309.     existence of applyLocalizedPattern.
  1310.  
  1311.     Added a convenience no argument constructor.
  1312.  
  1313. ____________
  1314. TEXT CHANGES - SortKey
  1315.  
  1316.     Renamed class CollationKey.  This keeps the terminology consistent 
  1317. with
  1318.     the other collation classes.
  1319.     
  1320.     Added getSourceString method.  This returns the string that this 
  1321.     CollationKey represents. This allows the removal of the 
  1322. CollatedString 
  1323.     class.
  1324.     
  1325.     Added a toByteArray method that returns a byte[] containing the 
  1326. key. 
  1327.     
  1328.     Changed compareTo method to return int rather than byte.  This 
  1329. follows the
  1330.     pattern set by java.lang.String.compareTo.
  1331.     
  1332. ____________
  1333. TEXT CHANGES - StringCharacterIterator
  1334.  
  1335.     Added the following convenience constructor:
  1336.     
  1337.       public StringCharacterIterator(String text, int begin, int end, 
  1338. int pos) 
  1339.     
  1340.     Renamed startIndex method to getBeginIndex.  Renamed endIndex 
  1341. method to
  1342.     getEndIndex. These names are consistent with the pattern for 
  1343. indicating 
  1344.     ranges in strings.
  1345.     
  1346.     Removed the getText method.  See the change description for 
  1347.     CharacterIterator.
  1348.  
  1349. ____________
  1350. TEXT CHANGES - TableCollation
  1351.  
  1352.     Renamed class RuleBasedCollator.  It was not clear from the old 
  1353. name 
  1354.     whether this class actually did collation or simply represented a 
  1355. set 
  1356.     of collation rules.  The new name makes it clear that the class 
  1357. performs 
  1358.     string comparisons. It also avoids the impression that this class 
  1359.     collates tables.
  1360.     
  1361.     Renamed getSortKey method to getCollationKey.  See the change 
  1362. description 
  1363.     for SortKey. 
  1364.     
  1365.     Removed the getSortKey method that operated on a substring of a 
  1366. given 
  1367.     String.  A recent change to String.substring makes the substring 
  1368.     operation efficient. Users can use String.substring to specify a 
  1369.     substring rather than requiring methods to provide substring 
  1370. variants. 
  1371.     Slimming the API makes it easier to learn.
  1372.     
  1373.     Removed the compare method that operated on a substring of a given 
  1374. String. 
  1375.     A recent change to String.substring makes the substring operation
  1376.     efficient. Users can use String.substring to specify a substring 
  1377. rather 
  1378.     than requiring methods to provide substring variants. Slimming the 
  1379. API 
  1380.     makes it easier to learn.
  1381.     
  1382.     Changed compare to return an int value instead of a byte value.  
  1383. See 
  1384.     the change description for Collation.
  1385.     
  1386. ____________
  1387. TEXT CHANGES - TextBoundary
  1388.  
  1389.     Renamed class to BreakIterator.  This more clearly reflects its 
  1390. purpose.
  1391.     
  1392.     Renamed method nthFromCurrent to next(int). This is a less awkward 
  1393. name.
  1394.     
  1395.     Renamed method nextAfter to following.  This is a less awkward 
  1396. name.
  1397.     
  1398.     Changed the return type of getText to CharacterIterator.  Since
  1399.     BreakIterator works in terms of a CharacterIterator it didn't make 
  1400. sense
  1401.     to return a String.
  1402.     
  1403.     Renamed getWorkBreak methods to getWordInstance.  Renamed 
  1404. getLineBreak
  1405.     methods to getLineInstance. Renamed getCharacterBreak methods to
  1406.     getCharacterInstance. Renamed getSentenceBreak methods to
  1407.     getSentenceInstance.  This follows the naming pattern for factory 
  1408. methods.
  1409.  
  1410. ____________
  1411. UTIL CHANGES - Calendar
  1412.  
  1413.     Changed the type of the public constants from byte to int.  Changed 
  1414. the
  1415.     corresponding methods to accept and return ints instead of bytes.  
  1416. and
  1417.     getDecomposition methods to return int instead of byte.  Although 
  1418. the byte
  1419.     type provides a small amount of type safety, using ints for 
  1420. constants is 
  1421.     more in keeping with the rest of the JDK.  The results are:
  1422.   
  1423.      byte ERA = 0;                  ==>   int ERA = 0;                  
  1424.      byte YEAR = 1;                 ==>   int YEAR = 1;                 
  1425.      byte MONTH = 2;                ==>   int MONTH = 2;                
  1426.      byte WEEKOFYEAR = 3;           ==>   int WEEK_OF_YEAR = 3;         
  1427.      byte WEEKOFMONTH = 4;          ==>   int WEEK_OF_MONTH = 4;        
  1428.      byte DATE = 5;                 ==>   int DATE = 5;                 
  1429.      byte DAYOFMONTH = 5;           ==>   int DAY_OF_MONTH = 5;         
  1430.      byte DAYOFYEAR = 6;            ==>   int DAY_OF_YEAR = 6;          
  1431.      byte DAYOFWEEK = 7;            ==>   int DAY_OF_WEEK = 7;          
  1432.      byte DAYOFWEEKINMONTH = 8;     ==>   int DAY_OF_WEEK_IN_MONTH = 8; 
  1433.      byte AMPM = 9;                 ==>   int AM_PM = 9;                
  1434.      byte HOUR = 10;                ==>   int HOUR = 10;                
  1435.      byte HOUROFDAY = 11;           ==>   int HOUR_OF_DAY = 11;         
  1436.      byte MINUTE = 12;              ==>   int MINUTE = 12;              
  1437.      byte SECOND = 13;              ==>   int SECOND = 13;              
  1438.      byte MILLISECOND = 14;         ==>   int MILLISECOND = 14;         
  1439.      byte ZONEOFFSET = 15;          ==>   int ZONE_OFFSET = 15;         
  1440.      byte DSTOFFSET = 16;           ==>   int DST_OFFSET = 16;          
  1441.      byte FIELDCOUNT = 17;          ==>   int FIELD_COUNT = 17;         
  1442.                                            
  1443.      int get(byte);                 ==>   int get(int);
  1444.      set(byte,int);                 ==>   void set(int,int);
  1445.      void clear(byte);              ==>   void clear(int);
  1446.      void add(byte,int);            ==>   void add(int,int);     
  1447.      void roll(byte,boolean);       ==>   void roll(int,boolean);
  1448.      void setFirstDayOfWeek(byte);  ==>   void setFirstDayOfWeek(int);
  1449.      void setMinimalDaysInFirstWeek(byte);
  1450.                                     ==>   void 
  1451. setMinimalDaysInFirstWeek(int);
  1452.      int getMinimum(byte);          ==>   int getMinimum(int);         
  1453.      int getMaximum(byte);          ==>   int getMaximum(int);         
  1454.      int getGreatestMinimum(byte);  ==>   int getGreatestMinimum(int); 
  1455.      int getLeastMaximum(byte);     ==>   int getLeastMaximum(int);    
  1456.                                                
  1457.     
  1458.     Renamed getValidationMode to isLenient.  Renamed setValidationMode 
  1459. to
  1460.     setLenient. These names are more descriptive.
  1461.     
  1462.     Renamed the getDefault methods to getInstance.  This is in keeping 
  1463. with the
  1464.     pattern for naming factory methods.
  1465.  
  1466. ____________
  1467. UTIL CHANGES - GregorianCalendar
  1468.  
  1469.     Changed the type of the public constants from byte to int.  Changed 
  1470. the
  1471.     corresponding methods to accept and return ints instead of bytes.  
  1472. and
  1473.     getDecomposition methods to return int instead of byte.  Although 
  1474. the byte
  1475.     type provides a small amount of type safety, using ints for 
  1476. constants 
  1477.     is more in keeping with the rest of the JDK.  The results are:
  1478.      
  1479.      final byte AD = 0;           ==>      final int AD = 0; 
  1480.      final byte BC = 1;           ==>      final int BC = 1; 
  1481.     
  1482.      void add(byte,int);          ==>      void add(int,int);          
  1483.      void roll(byte,boolean);     ==>      void roll(int,boolean);       
  1484.      int getMinimum(byte);        ==>      int getMinimum(int);          
  1485.      int getMaximum(byte);        ==>      int getMaximum(int);          
  1486.      int getGreatestMinimum(byte);==>      int getGreatestMinimum(int);  
  1487.      int getLeastMaximum(byte);   ==>      int getLeastMaximum(int);     
  1488.                                      
  1489. ____________
  1490. UTIL CHANGES - ResourceBundle
  1491.  
  1492.     Renamed getResourceBundle methods to getBundle.  The name
  1493.     getResourceBundle was too long and overly redundant.  The new name 
  1494. is not
  1495.     in keeping with the naming pattern for factory methods.  This is 
  1496. because
  1497.     the name "getInstance" is being reserved for a future addition to 
  1498. the
  1499.     resource bundle classes.
  1500.     
  1501. __________
  1502. AWT CHANGE -  Compiling programs that use old AWT API now produces
  1503.               deprecation warnings
  1504.  
  1505.     In the beta versions of 1.1, the deprecated methods in the AWT were
  1506.     marked with simple "DEPRECATED" strings in the method's javadoc
  1507.     comment.  For the final release we have added the appropriate
  1508.     "@deprecated" tags to those methods so that you can use the
  1509.     appropriate compiler option to generate warnings that make it
  1510.     easier for you to convert your programs when you desire to do so.
  1511.  
  1512.     The document at the following URL describes how to convert to the
  1513.     1.1 AWT API.  It also links to a document that lists every 
  1514. deprecated
  1515.     method and its 1.1 substitute.
  1516.  
  1517.     
  1518. http://java.sun.com/products/JDK/1.1/docs/guide/awt/HowToUpgrade.html
  1519.  
  1520.     RATIONALE:
  1521.  
  1522.     The bulk of the AWT deprecations are a result of migrating the AWT
  1523.     towards JavaBeans compliance.  In particular, the two areas which
  1524.     required a significant number of deprecations were:
  1525.  
  1526.     - Properties (location, size, visibility, etc.)
  1527.       In order for introspection to be able to programmatically extract
  1528.       properties from AWT components, it was necessary to change the
  1529.       names of various methods to the JavaBeans getFoo/setFoo pattern.
  1530.     
  1531.     - New event model
  1532.       JavaBeans and the AWT have defined a new delegation-based event
  1533.       model for 1.1 which required significant changes to the event
  1534.       handling API.
  1535.     
  1536.     Finally, a small set of deprecated methods were changed to enhance
  1537.     the learnability and consistency of the toolkit API.
  1538.  
  1539. __________
  1540. AWT CHANGE -  Z-ordering changed back to 1.0.2 order
  1541.  
  1542.     For beta3, the Z-ordering for children in Container instances was
  1543.     defined in the documentation to be "back to front".  Because this
  1544.     was contrary to the default Z-ordering which existed in 1.0.2 (and
  1545.     the beta implementation), for FCS we have corrected the Z-ordering
  1546.     specification in containers to be "front to back".
  1547.  
  1548. __________
  1549. AWT CHANGE -  Changed names of newly-added APIs:
  1550.  
  1551.     The following APIs have been renamed ( from old name => to new name 
  1552. ):
  1553.  
  1554.      AverageScaleFilter    =>    AreaAveragingScaleFilter
  1555.      createScaledImage(...)    =>    getScaledInstance(...)
  1556.      SCALE_AVERAGE        =>    SCALE_AREA_AVERAGING
  1557.  
  1558.     RATIONALE:
  1559.     The method name was changed to "getScaledInstance(...)" to be
  1560.     consistent with the overall philosophy within the Java API where
  1561.     factories and derivative constructors should follow the naming
  1562.     convention of
  1563.  
  1564.         get<Flavor>Instance(...arguments...)
  1565.  
  1566.     The term "Average" was not descriptive of the algorithm applied by
  1567.     the default smooth scaling filter, so the name of this filter and
  1568.     its algorithm were changed to "AreaAveraging" to indicate what
  1569.     quantity was being averaged.
  1570.  
  1571. __________
  1572. AWT CHANGE - Changed dispatchEvent() method and added new method
  1573.              dispatchEventImpl()
  1574.  
  1575.     The codepath in dispatchEvent() really must be executed for event
  1576.     mechanics to work properly in the AWT (hence we made it 
  1577.     package-private).  We moved the implementation to a new
  1578.     package-private method (dispatchEventImpl()) and then 
  1579.     changed dispatchEvent() to be "public final" and have it
  1580.     call dispatchEventImpl() internally.
  1581.  
  1582.     RATIONALE:
  1583.     We have deprecated the 1.0 postEvent()/deliverEvent() methods,
  1584.     however the method that replaces those (dispatchEvent()) is
  1585.     currently package-private.  This left no options for folks
  1586.     porting to the new event model.
  1587.  
  1588. __________
  1589. AWT CHANGE - Changed capitalization of getId() to getID() in
  1590.     java.awt.AWTEvent
  1591.  
  1592.     Changed the method name to getID() and provided a deprecated 
  1593. version
  1594.     for compatibility with the beta versions.
  1595.  
  1596.     RATIONALE:
  1597.     java.awt.AWTEvent.getID() is named in a manner inconsistent with 
  1598.     the equivalent methods in other classes:
  1599.     java.awt.MediaTracker.getID()
  1600.     java.util.TimeZone.getID()
  1601.     sun.rmi.registry.RegistryImpl.getID()
  1602.     sun.rmi.transport.DGCImpl.getID()
  1603.  
  1604.     Developers have had trouble because they expected the naming to 
  1605.     be consistent.  This fixes bug 4027793.
  1606.  
  1607. __________
  1608. AWT CHANGE - Changed EventQueue to be non-system-specific
  1609.  
  1610.   The following changes were made to EventQueue:
  1611.   
  1612.   1)  Moved the static getEventQueue() method out of EventQueue
  1613.       and instead put it in Toolkit with the name 
  1614. "getSystemEventQueue()".
  1615.       Left the security check in that method, so that applets 
  1616.       cannot get access to the system queue instance (see also #3).
  1617.   
  1618.   2)  Added a public constructor to the EventQueue class such that
  1619.       multiple instances of it can be created.  This will allow 
  1620. programs
  1621.       to create and use the queue generically, as well as enable 
  1622. browser
  1623.       vendors to implement a queue/dispatch-thread-per-applet model.
  1624.   
  1625.   3)  Removed the overriding checkAwtEventQueueAccess() method in the 
  1626.       AppletSecurityManager such that it will always default to
  1627.       invoking lang.SecurityManager.checkAwtEventQueueAccess()
  1628.       and will *always* throw a security exception if an applet tries
  1629.       to get a handle on the system event queue.
  1630.   
  1631.   4)  Modified the EventQueue documentation so that it's clear that
  1632.       the class is very generic.  All references to a "system
  1633.       EventQueue" have been eliminated.
  1634.  
  1635.     RATIONALE:
  1636.     This allows the implementation of one dispatch thread per applet.
  1637.     It also provides design flexibility for the future.
  1638.  
  1639. __________
  1640. AWT CHANGE - Removed EventSource class
  1641.  
  1642.     Removed this class because it has no relation to the new event 
  1643. model. 
  1644.  
  1645. __________
  1646. AWT CHANGE - Changed API for delivery of window-open and 
  1647.              window-closed events
  1648.  
  1649.     Moved the window event API (addWindowListener,removeWindowListener,
  1650.     etc.) from Dialog and Frame to Window (their superclass) so
  1651.     that the code is there in one place.  
  1652.  
  1653.     RATIONALE:
  1654.     Centralizing the code eliminates duplication and makes it easier 
  1655.     to maintain.
  1656.  
  1657. __________
  1658. AWT CHANGE - Changed return type from Transferable.getTransferData
  1659.  
  1660.     Transferable.getTransferData returns class BufferedInputStream.
  1661.  
  1662. __________
  1663. AWT CHANGE - MenuShortcut class no longer extends java.awt.Event.
  1664.  
  1665. __________
  1666. AWT CHANGE - Changed button modifier mask values in InputEvent:
  1667.         BUTTON2_MASK is now equivalent to ALT_MASK 
  1668.             BUTTON3_MASK is now equivalent to META_MASK
  1669.  
  1670.     RATIONALE:
  1671.     A couple of mask constants were incorrectly defined in the
  1672.     InputEvent class.  These event masks are new in JDK1.1.
  1673.     
  1674.     This change will ensure that programs that depend on seeing the
  1675.     BUTTON1_MASK and BUTTON2_MASK will continue to work properly on
  1676.     platforms that have 1 and 2 button mice (because Alt/Meta can be
  1677.     used to generate these masks on those systems).
  1678.  
  1679.     This fixes bug 4029159: Button2/Button3 masks should have same 
  1680.     value as Alt/Meta in InputEvent
  1681.     
  1682. __________
  1683. AWT CHANGE - Change to serialization of AWT components
  1684.  
  1685.     Made a systematic change to the way JDK1.1 AWT does serialization.
  1686.  
  1687.     RATIONALE:
  1688.     This change corrects bug #4027305, and provides more carefully 
  1689.     thought-out and rational behaviour for AWT serialization in 
  1690. general. 
  1691.  
  1692.     These changes enable customers to use serialization to store
  1693.     Java Beans (in general) and to enable AWT implementations 
  1694.     to correctly interoperate between vendors.
  1695.  
  1696.     Implications for developers:
  1697.   
  1698.       - Saving graphs of AWT objects will now work, even if an object
  1699.         has more than one listener.
  1700.   
  1701.       - If an AWT object has listeners that are marked serializable, 
  1702. they
  1703.         will be saved and restored automatically, such as beans 
  1704.         interconnected with and saved to a file with the BeanBox. 
  1705.         Note that the BeanBox always code-generates serializable 
  1706.         listener implementations.
  1707.       
  1708.       - If an AWT object has listeners that aren't marked serializable
  1709.         they will be dropped at writeObject() time.
  1710.   
  1711.       - Developers will need, as always, to consider the implications 
  1712. of
  1713.         making an object serializable.  One idiom to watch out for is 
  1714.         this:
  1715.   
  1716.         import java.awt.*;
  1717.         import java.awt.event.*;
  1718.         import java.io.Serializable;
  1719.   
  1720.         class MyApp implements ActionListener, Serializable
  1721.         {
  1722.           BigObjectThatShouldNotBeSeralizedWithAButton bigOne;
  1723.           Button aButton = new Button();
  1724.   
  1725.           MyApp()
  1726.           {
  1727.              // Oops, now aButton has a listener with a 
  1728.              // reference to bigOne!
  1729.              aButton.addActionListener(this);    
  1730.           }
  1731.   
  1732.           public void actionPerformed(ActionEvent e)
  1733.           {
  1734.             System.out.println("Hello There");
  1735.           }
  1736.         }
  1737.   
  1738.     In this example, serializing aButton by itself will cause MyApp and
  1739.     everything it refers to to be serialized as well.  The problem
  1740.     is that the listener is serializable by coincidence, not by design.
  1741.     To separate the decisions about MyApp and the ActionListener being 
  1742.     serializable one can use an inner (nested) class, for example:
  1743.   
  1744.     import java.awt.*;
  1745.     import java.awt.event.*;
  1746.     import java.io.Serializable;
  1747.   
  1748.     class MyApp java.io.Serializable
  1749.     {
  1750.       BigObjectThatShouldNotBeSeralizedWithAButton bigOne;
  1751.       Button aButton = new Button();
  1752.   
  1753.       class MyActionListener implements ActionListener
  1754.       {
  1755.         public void actionPerformed(ActionEvent e)
  1756.         {
  1757.       System.out.println("Hello There");
  1758.         }
  1759.       }
  1760.   
  1761.       MyApp()
  1762.       {
  1763.          aButton.addActionListener(new MyActionListener());
  1764.       }
  1765.     }
  1766.  
  1767. __________
  1768. AWT CHANGE - Added setKeyChar() method to KeyEvent
  1769.  
  1770.     KeyEvent had a setKeyCode() already. This new method was needed
  1771.     to copy any changes a 1.0 style program may have made
  1772.     to an Event "key".  This fix ensures that all chars work
  1773.     properly in TextFields, like hitting <return> in HotJava's URL 
  1774. field.
  1775.  
  1776. __________
  1777. AWT CHANGE - Changed PaintEvent class to use a rectangle for damaged 
  1778. area
  1779.  
  1780.     Replaced PaintEvent's "Graphics" property with a Rectangle 
  1781.     representing a damaged area instead.  
  1782.  
  1783.     RATIONALE:
  1784.     Although the PaintEvent class is public, its use in AWT 
  1785.     is completely private -- it is used to trigger calls to paint(), 
  1786.     but programs never explicitly see the event object at all.
  1787.  
  1788. __________
  1789. AWT CHANGE - Defined a new constant in AWTEvent:
  1790.         RESERVED_ID_MAX
  1791.  
  1792.     This new constant is the maximum value of any AWT-defined event ID.
  1793.     Programs that need to create their own event types should use
  1794.     an ID greater than this max ID, so that the event will be properly
  1795.     passed through the system.
  1796.  
  1797.     RATIONALE:
  1798.     This is part of the fix for a problem that prevented anyone from
  1799.     being able to create their own event type and send it to a
  1800.     component. 
  1801.  
  1802.     This fixes bug 4028353: eventEnabled returns false for all but 
  1803.     AWT events; can't send custom event types.
  1804.  
  1805. ____________
  1806. BEANS CHANGE - Improved handling of beans that are applets
  1807.  
  1808.     Changed Beans.instantiate to check if a newly created or 
  1809. deserialized
  1810.     bean is an Applet.  If so, it is given a minimal AppletStub and
  1811.     AppletContext and its init method is called.
  1812.  
  1813.     After developers have added a newly instantiated bean to an AWT
  1814.     container, they should check if it is an Applet and if so call
  1815.     Applet.start.
  1816.  
  1817.     Also, developers need to test "wanna-be" applet/beans against
  1818.     Beans.instantiate.
  1819.  
  1820. ____________
  1821. BEANS CHANGE - Serializable listener fix for Beans classes
  1822.  
  1823.     The java.beans package contains two utility classes, 
  1824.     PropertyChangeSupport and VetoableChangeSupport, that manage
  1825.     a list of event listeners.  The change was to make the way 
  1826.     these classes are serialized consistent with the AWT.
  1827.  
  1828.     RATIONALE
  1829.     In beta3 these two classes were inconsistent with the AWT,
  1830.     which meant there was no support for selectively saving and 
  1831.     restoring listeners marked serializable.  The changes are 
  1832.     all class private. 
  1833.  
  1834. _______________
  1835. SECURITY CHANGE - Key is now an interface
  1836.  
  1837.     Made Key an interface and updated relevant clients.  Removed all 
  1838.     implementation from Key to make it an interface. Moved its 
  1839.     implementation into sun.security.
  1840.  
  1841.     RATIONALE:
  1842.     Key as an interface is more flexible and easier to implement than 
  1843.     a mix of interfaces and classes.
  1844.  
  1845. _______________
  1846. SECURITY CHANGE - Changed names of factory methods
  1847.  
  1848.     Changed factory names from <Engine>.get<Engine> to get<Engine>.
  1849.  
  1850.     RATIONALE:
  1851.     Factory method names were MessageDigest.getMessageDigest, 
  1852.     Signature.getSignature, etc. A better naming scheme is 
  1853. Signature.get, 
  1854.     MessageDigest.get, etc. This is important when you start casting 
  1855. the 
  1856.     results to some fairly long interface names, for example:  
  1857.     DSAKeyGen keyGen = 
  1858. (DSAKeyGen)KeyGenerator.getKeyGenerator("DSA");
  1859.  
  1860. _______________
  1861. SECURITY CHANGE - Changed Provider SPI for java.security.Signature
  1862.     Initialization 
  1863.  
  1864.     The SPI is the Service Provider Interface, which Providers write 
  1865. to. 
  1866.     There currently are two providers: SUN and JSAFE.
  1867.  
  1868.     a) Changed the arguments to two initialization method in Signature
  1869.        from (byte[], String) to (Key)
  1870.     b) Made one method in key public.
  1871.     c) Added a small interface (no implementation): DSAPrivateKey
  1872.  
  1873.     Changed java.security.Signature and sun.security.provider.DSA.
  1874.  
  1875. _______________
  1876. SECURITY CHANGE- API changes to Signature, MessageDigest, and 
  1877.     KeyPairGenerator
  1878.  
  1879.     Signature
  1880.       public Signature get(String algorithm)     ->
  1881.       public Signature getInstance(String algorithm)
  1882.     
  1883.       public Signature get(String algorithm, String provider) ->
  1884.       public Signature getInstance(String algorithm, String provider)
  1885.  
  1886.     MessageDigest
  1887.       public MessageDigest get(String algorithm) ->
  1888.       public MessageDigest getInstance(String algorithm)
  1889.  
  1890.       public MessageDigest get(String algorithm, String provider) ->
  1891.       public MessageDigest getInstance(String algorithm, String 
  1892. provider)
  1893.  
  1894.     KeyPairGenerator
  1895.       public KeyPairGenerator get(String algorithm) ->
  1896.       public KeyPairGenerator getInstance(String algorithm)
  1897.     
  1898.       public KeyPairGenerator get(String algorithm, String provider) ->
  1899.       public KeyPairGenerator getInstance(String algorithm, String 
  1900. provider)
  1901.  
  1902. _______________
  1903. SECURITY CHANGE - Changed key generation API
  1904.  
  1905.     The change consisted of moving a set of existing methods from 
  1906.     Signature to a new KeyPairGenerator class.
  1907.  
  1908.     API change:
  1909.     a) Moved key generation calls from signature to a new
  1910.        KeyPairGenerator class
  1911.     b) Added a small DSAKeyPairGenerator interface, which specializes
  1912.        behavior for DSA key generation. 
  1913.  
  1914.     The change  consisted of moving 3 abstract API methods to a new 
  1915. class.
  1916.     - defined a KeyGenerator factory method (identical to
  1917.       Signature's).
  1918.     - added one line to ths sun.security.provider.DSA class.
  1919.     - added one line to ths sun.security.provider.Sun class.
  1920.     - updated API clients in JDK (there are two of them).
  1921.  
  1922.  
  1923.     RATIONALE:
  1924.     Customer feedback makes a strong case for moving the
  1925.     Signature class key generation calls into its own class. Key
  1926.     generation is currently implemented as part of the Signature
  1927.     class. While it provides a uniform, algorithm-independent
  1928.     key-generation semantics, it is hard to understand (and therefore 
  1929. to
  1930.     use). It has confused users both internally and externally.
  1931.   
  1932. __________
  1933. JAR CHANGE - Can now handle compressed JAR files in the CLASSPATH
  1934.  
  1935.     java.util.zip.ZipFile was enhanced so that it can now handle 
  1936.     compressed ZIP/JAR file entries. No changes to the API were made. 
  1937.     With this change, compressed JAR/ZIP files can now be handled
  1938.     by javac.
  1939.  
  1940.     Additionally, the runtime has also changed so that it can now
  1941.     handle compressed ZIP/JAR files that are specified in the 
  1942. CLASSPATH.
  1943.  
  1944. ___________
  1945. LANG CHANGE - Removed a constructor and two methods from 
  1946. java.lang.Throwable
  1947.  
  1948.     - Removed the Throwable(String, Object[]) constructor 
  1949.     - Removed the setArguments() method 
  1950.     - Removed the getArguments() method 
  1951.  
  1952.     RATIONALE:
  1953.     The arguments property was originally added to java.lang.Throwable 
  1954. for 
  1955.     use in the generation of localized messages.  This was deemed 
  1956. premature, 
  1957.     and so the property was removed in order to avoid tempting 
  1958. programmers 
  1959.     to use it for some other purpose.
  1960.  
  1961. _________
  1962. IO CHANGE - Deprecated constructor StreamTokenizer(InputStream)
  1963.  
  1964.     This fixed bug 4025998.
  1965.  
  1966.     RATIONALE:
  1967.     The StreamTokenizer(InputStream) constructor was not 
  1968. binary-compatible 
  1969.     with JDK 1.0.2.  This constructor was changed in JDK1.1 to convert 
  1970.     automatically from bytes to characters using the platform's default
  1971.     character encoding, but that change required buffering input data, 
  1972.     which breaks binary compatibility.  This change has been removed.
  1973.  
  1974. ____________________________
  1975. JAVA NATIVE INTERFACE CHANGE - Changed the names of VM initialization
  1976. and thread-attach structures
  1977.  
  1978.     Changed the JDK initialization structure name from JavaVMInitArgs 
  1979. to 
  1980.     JDK1_1InitArgs to make it clear that it is JDK1.1 specific.
  1981.  
  1982.     Similarly, ThreadAttachArgs has changed its name to 
  1983. JDK1_1AttachArgs.
  1984.  
  1985.     RATIONALE:
  1986.     When a native application uses the invocation API to start up
  1987.     the VM, it passes the VM an initialization structure. Since in
  1988.     general different VM implementations require different 
  1989.     initialization information (min/max heap size, native stack size,
  1990.     enable debugging, etc.), the JNI spec explicitly says
  1991.     that the contents of the structure vary among VM implementations.
  1992.     However, the JDK initialization structure, JavaVMInitArgs, gives 
  1993.     the wrong impression that it should work with other VMs. This has
  1994.     caused confusion on how to implement the JNI without conflicting
  1995.     with JDK's naming scheme.
  1996.  
  1997. ____________________________
  1998. JAVA NATIVE INTERFACE CHANGE - Changed NewStringUTF parameters
  1999.  
  2000.     Removed the length argument, strlen(s, from NewStringUTF().  The
  2001.     signature for this method is now:
  2002.  
  2003.     jstring NewStringUTF(JNIEnv *env, const char *s);
  2004.  
  2005.     RATIONALE:
  2006.     NewStringUTF constructs a Java string from a UTF string. Although 
  2007.     UTF strings are already 0-terminated, the function required an
  2008.     unnecessary length argument, forcing the programmer to write:
  2009.  
  2010.     NewStringUTF(env, s, strlen(s))
  2011.  
  2012.     instead of just:
  2013.  
  2014.     NewStringUTF(env, s) 
  2015.  
  2016. ____________________________
  2017. JAVA NATIVE INTERFACE CHANGE - Changed DeleteLocalRef and 
  2018. DeleteGlobalRef
  2019.  
  2020.     Now programmers can pass local or global references to 
  2021. DeleteLocalRef 
  2022.     and DeleteGlobalRef directly, instead of having to pass the address 
  2023.     of these references.
  2024.  
  2025.     RATIONALE:
  2026.     DeleteLocalRef and DeleteGlobalRef delete local or global 
  2027. references
  2028.     created by the JNI. They used to take the address of the reference,
  2029.     forcing programmers to write:
  2030.  
  2031.     DeleteLocalRef(&ref)
  2032.  
  2033.     now references are passed as follows:
  2034.  
  2035.     DeleteLocalRef(ref)
  2036.  
  2037. ____________________________
  2038. JAVA NATIVE INTERFACE CHANGE - Changed the "IsSubclassOf" function name
  2039.     to "IsAssignableFrom."
  2040.  
  2041.     RATIONALE:
  2042.     The following JNI (Java Native Interface) function was misnamed:
  2043.  
  2044.         jboolean IsSubclassOf(JNIEnv *env, jclass clazz1, 
  2045.                                            jclass clazz2);
  2046.  
  2047.     It did not match the Java Language Specification's definition 
  2048.     of the "subclass" relationship.
  2049.  
  2050.     The Reflection API has a similar method in java.lang.Class:
  2051.     
  2052.         boolean isAssignableFrom(Class class);
  2053.         
  2054.     This is a much more suitable name. The JNI function therefore 
  2055. changed 
  2056.     its name to:
  2057.     
  2058.         jboolean IsAssignableFrom(JNIEnv *env, jclass clazz1, 
  2059.                                                jclass clazz2);
  2060.  
  2061. ____________________________
  2062. JAVA NATIVE INTERFACE CHANGE - Change RegisterNatives so that it
  2063.     takes all the information in one array.
  2064.  
  2065.     RATIONALE:
  2066.     In beta3, the RegisterNatives function took three arrays
  2067.     containing native method names, signatures and function entry 
  2068.     pointers, respectively:
  2069.     
  2070.         jint RegisterNatives(JNIEnv env, jclass clazz, 
  2071.                const char *names[],
  2072.                const char *signatures[];
  2073.                void *nativeProcs[]);
  2074.          
  2075.     These arrays had to be of the same length, and had to be NULL-
  2076.     terminated. It's better to put all the info in a single array,
  2077.     and pass the length of the array as another argument:
  2078.     
  2079.         struct JNINativeMethod {
  2080.             char* name;
  2081.             char* signature;
  2082.             void* fnPtr;
  2083.         };
  2084.         typedef struct JNINativeMethod JNINativeMethod;
  2085.  
  2086.         void RegisterNatives(JNIEnv* env, jclass classID, 
  2087.                   const JNINativeMethod methods[], jsize count);
  2088.  
  2089.     Here's how code that uses this looks in FCS:
  2090.  
  2091.         JNINativeMethodSpec methods[] = {
  2092.             { "sin", "(D)D", &::sin },
  2093.             { "cos", "(D)D", &::cos },
  2094.             { "tan", "(D)D", &::tan }
  2095.         };
  2096.         env->RegisterNatives(env->FindClass("java/lang/Math"), methods, 
  2097. 3);
  2098.  
  2099.     Here's how the same code used to look in beta3:
  2100.  
  2101.         const char* names[] = { "sin", "cos", "tan", NULL };
  2102.         const char* signatures[] = { "(D)D", "(D)D", "(D)D", NULL };
  2103.         void* procs[] = { &::sin, &::cos, &::tan, NULL };
  2104.         env->RegisterNatives(env->FindClass("java/lang/Math"), 
  2105.                              names, signatures, proc);
  2106.     
  2107.     The former approach is clearer.
  2108.  
  2109. ____________________________
  2110. JAVA NATIVE INTERFACE CHANGE - Changed the typing scheme of references
  2111.     to Java objects.
  2112.  
  2113.     In JDK Beta 3, reference types are defined as follows:
  2114.  
  2115.     typedef void *jref;    /* generic type for references */
  2116.     typedef jref jobject;  /* Java objects */
  2117.     typedef jref jclass;   /* Java class objects */
  2118.     typedef jref jstring;  /* Java strings */
  2119.     typedef jref jarray;   /* Java arrays */
  2120.  
  2121.     The distinction between jref and jobject was not clear. In 1.1 FCS,
  2122.     we got rid of jref, and introduced additional reference types to 
  2123. more
  2124.     accurately convey the subtyping information. We introduced dummy 
  2125. C++
  2126.     classes to enforce the subtyping relationships:
  2127.  
  2128.     #ifdef __cplusplus
  2129.  
  2130.     class _jobject {};
  2131.     class _jclass : public _jobject {};
  2132.     class _jthrowable : public _jobject {};
  2133.     class _jstring : public _jobject {};
  2134.     class _jarray : public _jobject {};
  2135.     class _jbooleanArray : public _jarray {};
  2136.     class _jbyteArray : public _jarray {};
  2137.     class _jcharArray : public _jarray {};
  2138.     class _jshortArray : public _jarray {};
  2139.     class _jintArray : public _jarray {};
  2140.     class _jlongArray : public _jarray {};
  2141.     class _jfloatArray : public _jarray {};
  2142.     class _jdoubleArray : public _jarray {};
  2143.     class _jobjectArray : public _jarray {};
  2144.  
  2145.     typedef _jobject *jobject;
  2146.     typedef _jclass *jclass;
  2147.     typedef _jthrowable *jthrowable;
  2148.     typedef _jstring *jstring;
  2149.     typedef _jarray *jarray;
  2150.     typedef _jbooleanArray *jbooleanArray;
  2151.     typedef _jbyteArray *jbyteArray;
  2152.     typedef _jcharArray *jcharArray;
  2153.     typedef _jshortArray *jshortArray;
  2154.     typedef _jintArray *jintArray;
  2155.     typedef _jlongArray *jlongArray;
  2156.     typedef _jfloatArray *jfloatArray;
  2157.     typedef _jdoubleArray *jdoubleArray;
  2158.     typedef _jobjectArray *jobjectArray;
  2159.  
  2160.     #else
  2161.  
  2162.     struct _jobject;
  2163.  
  2164.     typedef struct _jobject *jobject;
  2165.     typedef jobject jclass;
  2166.     typedef jobject jthrowable;
  2167.     typedef jobject jstring;
  2168.     typedef jobject jarray;
  2169.     typedef jarray jbooleanArray;
  2170.     typedef jarray jbyteArray;
  2171.     typedef jarray jcharArray;
  2172.     typedef jarray jshortArray;
  2173.     typedef jarray jintArray;
  2174.     typedef jarray jlongArray;
  2175.     typedef jarray jfloatArray;
  2176.     typedef jarray jdoubleArray;
  2177.     typedef jarray jobjectArray;
  2178.  
  2179.     #endif
  2180.  
  2181.     JNI function types have been modified accordingly to accept or 
  2182. return
  2183.     the newly introduced reference types.
  2184.  
  2185. ____________________________
  2186. JAVA NATIVE INTERFACE CHANGE - Changed the typing of certain primitive
  2187.     types:
  2188.  
  2189.     The following types in earlier versions of JDK:
  2190.  
  2191.     typedef char jboolean;
  2192.     typedef char jbyte;
  2193.     typedef unsigned long jsize;
  2194.  
  2195.     have been changed to:
  2196.  
  2197.     typedef unsigned char jboolean;
  2198.     typedef signed char jbyte;
  2199.     typedef jint jsize;
  2200.  
  2201.     in JDK 1.1 FCS.
  2202.  
  2203.     Earlier, jsize was defined to be an unsigned integer type that has
  2204.     the same number of bits as a native pointer. The idea was to use
  2205.     jsize to represent array length and size, etc. However, there has
  2206.     been a great deal of confusion on what operations are available 
  2207.     on jsize, whether it is safe to convert jsize to int, etc. We
  2208.     changed jsize to be the same as jint because Java arrays and
  2209.     strings cannot be longer than 2^31 anyway. All standard Java
  2210.     methods that operate on arrays and strings use "int" as the
  2211.     length and size types.
  2212.  
  2213. ___________
  2214. TOOL CHANGE - New argument -s added to javap
  2215.  
  2216.     -s: Print method and field type signature information in the 
  2217. internal
  2218.         form used by the Java Virtual Machine.  This is the form 
  2219. through
  2220.         which a user of the Java Native Interface (JNI) refers to 
  2221. methods
  2222.         and fields. Using javap with the -s flag to print method and 
  2223. field
  2224.         information for a class to be accessed with the JNI avoids the 
  2225.         difficulty of constructing signatures in the obscure internal 
  2226.         format manually.
  2227.     
  2228.     Examples of use:
  2229.  
  2230.     % cat foo.java
  2231.     class foo {
  2232.         Thread thread;
  2233.         int i;
  2234.         public static void main(String args[]) {
  2235.         }
  2236.         private void foo() {}
  2237.     }
  2238.  
  2239.     % javap -p foo
  2240.     Compiled from foo.java
  2241.     class foo extends java.lang.Object 
  2242.         /* ACC_SUPER bit set */ 
  2243.     {
  2244.         java.lang.Thread thread;
  2245.         int i;
  2246.         public static void main(java.lang.String []);
  2247.         private void foo();
  2248.         foo();
  2249.     }
  2250.  
  2251.     % javap -p -s foo
  2252.     Compiled from foo.java
  2253.     class foo extends java.lang.Object 
  2254.         /* ACC_SUPER bit set */
  2255.     {
  2256.         thread Ljava/lang/Thread;
  2257.         i I
  2258.         public static main ([Ljava/lang/String;)V
  2259.         private foo ()V
  2260.         <init> ()V
  2261.     }
  2262.  
  2263. ___________
  2264. TOOL CHANGE - Added -deprecation flag to javac
  2265.  
  2266.     By default, when compiling a class that contains deprecated APIs, 
  2267.     javac now displays only a brief note, rather than immediately
  2268.     listing all of the deprecated APIs.  For example:
  2269.  
  2270.     % javac MyClass.java
  2271.     Note: MyClass.java uses deprecated APIs.  Recompile with 
  2272. "-deprecation" 
  2273.     for details.
  2274.  
  2275.     Then, you can re-compile using the -deprecation flag to get the
  2276.     name of the deprecated constructor, field, method, class or 
  2277.     interface.
  2278.  
  2279.     % javac -deprecation MyClass.java
  2280.     MyClass.java:3: Note: The constructor java.lang.String(byte[],int)
  2281.     has been deprecated.
  2282.         new String(new byte[0], 0);
  2283.         ^
  2284.     Note: wombat.java uses deprecated APIs.  Please consult the 
  2285.     documentation for a better alternative.
  2286.  
  2287.     At this point, please refer to the JDK API Reference documentation
  2288.     (the javadoc-generated web pages) jdk1.1/docs/api/packages.html.
  2289.     If you look up the deprecated API, it should give you more details
  2290.     such as which API replaces it.    
  2291.  
  2292.     To summarize the compiler options:
  2293.         javac -nowarn       => complete silence
  2294.         javac               => a one-line comment about deprecations
  2295.         javac -deprecation  => a full report
  2296.  
  2297.     RATIONALE:
  2298.     This can greatly reduce the amount of warning by default, allowing 
  2299.     developers to concentrate on the errors, and to have a graceful
  2300.     migration towards updating their deprecated code.
  2301.  
  2302.  
  2303. ===================================================================
  2304. Changes from JDK 1.1beta2 to JDK 1.1beta3
  2305. -------------------------------------------------------------------
  2306.  
  2307. The following changes and bug fixes are in the JDK 1.1beta3 release.
  2308.  
  2309. ______________
  2310. VERSION NUMBER - The version number for this release is 
  2311. "JDK1.1beta3.3". 
  2312.  
  2313.     Versions beta3.1 and beta3.2 were internal candidates that were 
  2314.     never released.
  2315.     You can get the version number of your particular release by 
  2316. executing:
  2317.  
  2318.         java -version
  2319.  
  2320. _______________
  2321. PACKAGE CHANGES - Two new packages in java.*: java.beans and java.math
  2322.     Changes in these packages are described in more detail below.
  2323.  
  2324. ________________
  2325. JAVABEANS CHANGE - JavaBeans1.0 is now part of JDK1.1
  2326.     The classes that define the JavaBeans 1.0 API specification
  2327.     are now part of JDK1.1.  These classes are part of BDK1.0
  2328.     beta1 and beta2; there will be a BDK1.0beta3 that synchronizes
  2329.     with JDK1.1beta3.
  2330.  
  2331.   - There has been one change in the JavaBeans APIs: the string
  2332.     argument to Beans.instantiate() has changed. The argument
  2333.     used to be the path to a serialized bean, it is now the
  2334.     name of a bean, which may be serialized, or just a class name.
  2335.  
  2336. ______________
  2337. GENERAL CHANGE - Extended the core API methods that take a PrintStream 
  2338.     argument so they can also take a PrintWriter argument.
  2339.  
  2340.     Several constructors and methods have been added to make the 
  2341.     new PrintWriter class easier to use.  
  2342.  
  2343. _________
  2344. IO CHANGE - Merged the functionality of the ByteToCharConverter 
  2345.     and CharToByteConverter classes into the InputStreamReader and
  2346.     OutputStreamWriter classes.
  2347.  
  2348.     The ByteToCharConverter and CharToByteConverter classes 
  2349.     are no longer public, so various constructors and methods
  2350.     that previously took converter arguments now accept names
  2351.     of character encodings.  The InputStreamReader and 
  2352.     OutputStreamWriter classes no longer commit to buffering
  2353.     the underlying byte stream.  Details on these and other
  2354.     changes may be found at:
  2355.  
  2356.     http://java.sun.com/products/JDK/1.1/docs/guide/io/b3-changes.html
  2357.  
  2358. ___________
  2359. LANG CHANGE - New method: identityHashCode in java.lang.System
  2360.  
  2361.     Its signature is:
  2362.  
  2363.     public static native int identityHashCode(Object x);
  2364.  
  2365.     It returns the same hashcode for the given object as
  2366.     would be returned by the default method hashCode(),
  2367.     whether or not the given object's class overrides hashCode().
  2368.     The hashcode for the null reference is zero.
  2369.  
  2370.     RATIONALE:  
  2371.     In previous releases, Java lacked a constant-time
  2372.     identity hash function.  This meant there was no way to build
  2373.     a hash table which keyed on object identity, and for which
  2374.     access would be a constant-time operation.
  2375.  
  2376.     Java supplied a constant-time identity comparison operation 
  2377.     (the built-in operator ==) but did not supply a corresponding
  2378.     constant-time identity hash operation.
  2379.  
  2380.     This new method is very useful when the object in question does
  2381.     override equals and hashCode, but the guts of some abstraction
  2382.     is working with canonicalized instances, such as interned 
  2383.     strings, and needs to use them as keys for fast lookups.
  2384.  
  2385.     Although this is sometimes done by wrapping the string-like
  2386.     object inside another object which does not override equals 
  2387.     and hashCode, it's desirable to allow such objects to be used
  2388.     directly as keys in identity tables, to avoid the overhead 
  2389.     of allocating the wrappers.
  2390.  
  2391.     When performance is not an issue, the method Object.hashCode() 
  2392.     suffices, even if it is slow (as with strings), but when
  2393.     performance must be maximized, neither the wrapper technique 
  2394.     nor the slow hashCode() method is workable, and only a fast
  2395.     identityHashCode() method will be suitable.
  2396.  
  2397. ___________
  2398. LANG CHANGE - getResourceAsName(String) changed to getResource(String)
  2399.  
  2400.     java.lang.Class and java.lang.ClassLoader used to have methods 
  2401.     with signature:
  2402.  
  2403.        String getResourceAsName(String)
  2404.  
  2405.     which would return an external representation to a URL to
  2406.     the desired resource file.  These methods have been replaced
  2407.     by methods with signature
  2408.  
  2409.        java.net.URL getResource(String)
  2410.  
  2411.     which return the actual URL (or null if the resource is not found).
  2412.  
  2413. ___________
  2414. AWT CHANGES - New type of event: ContainerEvent
  2415.  
  2416.   This change provides the hooks for containers to easily register 
  2417. event 
  2418.   listeners on descendents.
  2419.  
  2420.   - Added new ContainerEvent class and equivalent ContainerListener 
  2421.     interface to enable notification when components are added/removed
  2422.     from containers.  This makes it relatively easy for containers 
  2423.     to register themselves as listeners for events on all of their 
  2424.     descendents.
  2425.  
  2426.   - Added the addContainerListener/removeContainerListener methods
  2427.     to Container.
  2428.  
  2429.   RATIONALE:
  2430.   In beta2 the event model provided no reasonable mechanism
  2431.   to allow containers to get input events which occurred in their
  2432.   descendents, which turns out to be a fairly common need.
  2433.   The 1.0 event model allowed this by automatically propagating
  2434.   events up the containment hierarchy until some component returned
  2435.   "true" to absorb the event and stop the propagation.  While this
  2436.   seems powerful (and it's easy), the 1.0 propagation model is error
  2437.   prone and results in poor performance. 
  2438.      
  2439. ___________
  2440. AWT CHANGES - Further Fine-Tuning of AWT Input Event Related API
  2441.  
  2442.   Responding to customer feedback and testing, we made the following
  2443.   changes to the API in the java.awt and java.awt.event packages:
  2444.  
  2445.   - Added a TextEvent class and TextListener interface to enable
  2446.     programs to track all changes to a text component, including
  2447.     paste and programmatic modifications.  (Bug #4014945)
  2448.  
  2449.   - Added new windowActivated/windowDeactivated event types to 
  2450. WindowEvent 
  2451.     to enable programs to determine when a window gets/loses focus.
  2452.   
  2453.   - Added isTemporary method to FocusEvent to enable determining the
  2454.     difference between when focus is explicitly moved between 
  2455. components
  2456.     and when focus temporarily changes (such as when a window is
  2457.     de-activated).
  2458.   
  2459.   - Added a consume method to the InputEvent class, enabling any object
  2460.     to consume input events.  Previously, only the Component associated
  2461.     with the input event could consume it.
  2462.  
  2463.   - Made the AWTEventMulticaster class public, enabling component
  2464.     subclasses to serve as multicast sources for AWT-defined events.
  2465.   
  2466.   - Made the java.awt.event Adapter classes abstract so that it's clear
  2467.     that they need to be extended.
  2468.  
  2469.   - Removed constructors in java.awt.event Event classes that took
  2470.     an old 1.0 event as a parameter.
  2471.   
  2472.   - Changed the event id values of the ComponentEvent types to prevent 
  2473. them
  2474.     from clashing with the WindowEvent ids.
  2475.   
  2476.   - Added virtual keycode identifiers to KeyEvent to properly represent
  2477.     all standard keys on the keyboard.  The keyCode property of the key
  2478.     event now contains one of those identifiers (instead of the ASCII
  2479.     integer equivalent).
  2480.  
  2481.   - Added a method called isPopupTrigger to the MouseEvent class,
  2482.     providing a platform-independent way to determine whether a mouse
  2483.     event should result in a popup menu being shown. (Bug #4017794)
  2484.  
  2485. __________
  2486. AWT CHANGE - New method: getTreeLock() to java.awt.Component:
  2487.  
  2488.     The public field Component.LOCK will NOT be changed for beta3,
  2489.     to minimize the risk of the change for beta3, but it will be made
  2490.     non-public (package private) between beta3 and final release.
  2491.  
  2492.     RATIONALE:
  2493.     The AWT exposes a public static final field, called Component.LOCK, 
  2494.     for synchronizing operations that affect or depend on
  2495.     component-tree structure.  
  2496.  
  2497.     Exposing this field for public use unnecessarily constricts future
  2498.     AWT implementations to providing a single toolkit-wide lock.
  2499.  
  2500.     It is much better to provide access to the lock object by an
  2501.     instance method on class Component, such that future
  2502.     implementations can return a context-sensitive locking object if
  2503.     they need to.
  2504.  
  2505. __________
  2506. AWT CHANGE - New Component method: getLocationOnScreen
  2507.  
  2508.     Added one new method to the Component class:
  2509.  
  2510.       Point getLocationOnScreen()
  2511.  
  2512.     RATIONALE:
  2513.     This method returns the current location of the component in
  2514.     the screen's coordinate space.
  2515.  
  2516. __________
  2517. AWT CHANGE - New Choice method: insert
  2518.  
  2519.     Added one new method to the Choice class:
  2520.  
  2521.       void insert(String item, int index) 
  2522.  
  2523.     RATIONALE:
  2524.     This method lets you insert items into a Choice control at the 
  2525. index
  2526.     you specify.  (In Beta2, items were always added at the end.)
  2527.  
  2528. __________
  2529. AWT CHANGE - ItemSelectable interface change 
  2530.  
  2531.     Removed the following two methods from the ItemSelectable 
  2532. interface:
  2533.        public int[] getSelectedIndexes();
  2534.        public String[] getSelectedItems();
  2535.  
  2536.     They have been replaced by the following method:
  2537.        public Object[] getSelectedObjects();
  2538.  
  2539.     RATIONALE:
  2540.     This change removes the restriction that an item must be 
  2541. representable
  2542.     by a String.  The AWT classes that implement ItemSelectable (List,
  2543.     Choice, Checkbox, and CheckboxMenuItem) have changed accordingly.
  2544.  
  2545. __________
  2546. AWT CHANGE - Allow Container and Component classes to be extended 
  2547.     directly to create lightweight components.
  2548.  
  2549.   1) Added the following method to java.awt.Component
  2550.  
  2551.     Dimension getMaximumSize();
  2552.  
  2553.      In beta2 components could specify only their minimum and preferred
  2554.      sizes and assume that the component was infinitely stretchable.  
  2555.      This assumption is invalid with lightweight components where 
  2556. components
  2557.      tend to be written at a finer granularity and some components 
  2558. don't
  2559.      want to be flexible.
  2560.  
  2561.      The default implementation of this method specifies infinite
  2562.      size to reflect the current behavior.
  2563.  
  2564.   2) Added two alignment functions to java.awt.Component.
  2565.  
  2566.         float getAlignmentX();
  2567.     float getAlignmentY();
  2568.  
  2569.      that return a number between 0.0 and 1.0.  These values specify 
  2570. how 
  2571.      to align the component relative to other components.  0.0 would be
  2572.      aligned at the origin, 1.0 the furthest away from the origin, 
  2573.      0.5 is centered, etc.  As examples, a text component would have a
  2574.      y alignment to the baseline, and an icon component would have 
  2575.      an alignment to its hotspot, if defined.
  2576.  
  2577.     RATIONALE:
  2578.     Before beta3 the only way of creating new components in the AWT was
  2579.     to extend Canvas, Panel, and their subclasses.  Component and
  2580.     Container could not be directly extended.  All components were
  2581.     automatically "heavyweight" in that each had an opaque native
  2582.     window associated with them.  The problem with this is that 
  2583. heavyweight
  2584.     components are expensive (you can't afford to have too many) and
  2585.     they cannot have any transparent pixels.  The new changes create
  2586.     standard support for lightweight components.
  2587.  
  2588. ____________
  2589. MATH CHANGES - New package: java.math, which initially contains two 
  2590.     classes:  BigInteger and BigDecimal.
  2591.  
  2592.     BigNum class has been removed and replaced by BigInteger and 
  2593. BigDecimal.
  2594.  
  2595.     BigIntegers are immutable arbitrary-precision integers, which 
  2596. provide
  2597.     analogs to all of Java's primitive integer operators, and all 
  2598. relevant
  2599.     static methods from java.lang.Math.  Additionally, BigIntegers 
  2600. provide
  2601.     operations for modular arithmetic, GCD calculation, primality 
  2602. testing, 
  2603.     prime generation, single-bit manipulation, and a few other odds and 
  2604. ends.
  2605.  
  2606.     BigDecimals are immutable, arbitrary-precision signed decimal 
  2607. numbers,
  2608.     suitable for monetary calculations.  BigDecimals provide operations 
  2609. for 
  2610.     basic arithmetic, scale manipulation, comparison, format conversion 
  2611.     and hashing.  The BigDecimal class gives its user complete control 
  2612.     over rounding behavior, forcing the user to explicitly specify a 
  2613.     rounding behavior for operations capable of discarding precision.
  2614.  
  2615. ________________
  2616. SECURITY CHANGES -  New method: getProviders(), which provides 
  2617.     a way to query which crypto providers are installed.
  2618.  
  2619.     This method is added to the Security class and has the form:
  2620.  
  2621.     public static String[] getProviders();
  2622.  
  2623. ___________
  2624. TOOL CHANGE - javakey is now able to export keys and certs
  2625.     to files.
  2626.  
  2627.     This is a change to the javakey tool, a reciprocal to
  2628.     the existing import facility.
  2629.  
  2630. ___________
  2631. TOOL CHANGE - javac -nowarn flag now suppresses @deprecated messages  
  2632.  
  2633.     This can greatly reduce the amount of messages, allowing you
  2634.     to see only the errors.
  2635.  
  2636. ____________
  2637. TOOL CHANGES - jar tool is incompatible with earlier JAR files
  2638.  
  2639.     The beta3 jar tool (more specifically, ZipInputStream and
  2640.     ZipOutputStream) is incompatible with JAR files created with
  2641.     the beta2 jar tool.  The JAR tool won't understand those files.
  2642.     There was a bug in beta2 ZipInputStream and ZipOutputStream 
  2643.     such that those classes didn't generate files properly according
  2644.     to the zip specification (one bit out of place means a lot...)
  2645.     The bug was fixed and now it generates proper zip files that 
  2646.     other tools will understand.
  2647.  
  2648. ____________
  2649. TOOL CHANGES - Removed ability to generate MIF from javadoc
  2650.  
  2651.     Removed "-doctype MIF" option from javadoc.  This was necessary
  2652.     in order to remove the HTML parser dependency that HotJava had
  2653.     on the JDK.
  2654.  
  2655. ===================================================================
  2656. Changes from the original JDK 1.1beta to JDK 1.1beta2
  2657. -------------------------------------------------------------------
  2658.  
  2659. The following fixes and improvements are in the JDK 1.1beta2 release.
  2660.  
  2661. ______________
  2662. VERSION NUMBER - The version number for this release is "JDK1.1beta2". 
  2663.  
  2664.     You can get the version number of your particular release by 
  2665. executing:
  2666.  
  2667.         java -version
  2668.  
  2669. _______
  2670. CHANGE - Source code for public classes included
  2671.  
  2672.     The source code for the public classes in the java.* package are 
  2673.     now included in this release in the file src.zip.  These correspond
  2674.     to the public classes contained in classes.zip.  This src.zip
  2675.     is equivalent to that shipped previously with JDK 1.0.2
  2676.     but also includes sources to the new public classes added in JDK 
  2677. 1.1. 
  2678.  
  2679. _______
  2680. BUG FIX - Jar tool manifest-build limitation on number of files on 
  2681. Solaris
  2682.  
  2683.     DESCRIPTION OF BUG
  2684.     In some configurations of Solaris, trying to create a JAR file 
  2685.     that has more than 64 entries in it would fail.  The command 
  2686.     that would cause this to happen is:
  2687.  
  2688.     % jar cvf test.jar <somedir>
  2689.   
  2690.     where <somedir> is a directory containing more than 64 files.
  2691.  
  2692.     SOLUTION - This bug has been fixed.
  2693.  
  2694. _______
  2695. BUG FIX - Javakey tool signs jar files with invalid signatures
  2696.  
  2697.     DESCRIPTION OF BUG
  2698.     An implementation inconsistency in the javakey security tool causes
  2699.     jar files to be signed with invalid signatures. This means that 
  2700.     signature checking will always fail, thus all applets will run as 
  2701.     untrusted, with minimal permissions enabled.  This makes code 
  2702. signing
  2703.     feature unusable but it is not a security hole.  
  2704.  
  2705.     SOLUTION - This bug has been fixed. 
  2706.  
  2707. _______
  2708. BUG FIX - 4017054 - Limit to numeric range of case statements
  2709.  
  2710.     DESCRIPTION OF BUG
  2711.     If a Java switch statement includes case statements that cover a 
  2712. wide
  2713.     range of numerical values (although not necessarily a large number 
  2714. of 
  2715.     cases themselves), the Java compiler can run out of memory 
  2716. attempting 
  2717.     to compile that statement.  For instance, a switch statement 
  2718.     containing the two cases 0 and 99999999 will cause the compiler to 
  2719.     run out of memory.
  2720.  
  2721.     SOLUTION - This bug has been fixed.
  2722.  
  2723. _______
  2724. BUG FIX - 4018832 - Missing class java.io.LineNumberReader
  2725.  
  2726.     DESCRIPTION OF BUG
  2727.     In the Win32 release, the class java.io.LineNumberReader is
  2728.     documented but the class file is absent from classes.zip
  2729.  
  2730.     SOLUTION - java.io.LineNumberReader has been added to classes.zip
  2731.  
  2732. _______
  2733. BUG FIX - 4018252 - DecimalNumberFormat methods throw exceptions
  2734.  
  2735.     DESCRIPTION OF BUG
  2736.     The class java.text.DecimalNumberFormat throws an exception when 
  2737. any 
  2738.     of its format or parse methods are called.  A typical stack trace 
  2739.     looks something like the following:
  2740.  
  2741.     java.lang.NumberFormatException: 451.0D
  2742.         at java.lang.Double.<init>(Double.java)
  2743.         at java.text.DigitList.getRealDouble(DigitList.java)
  2744.         at java.text.DigitList.set(DigitList.java)
  2745.         at java.text.DecimalFormat.format(DecimalFormat.java)
  2746.         at java.text.NumberFormat.format(NumberFormat.java)
  2747.  
  2748.     Although DecimalNumberFormats are generally not used directly, they 
  2749.     are returned by calls to NumberFormat.getDefault(), 
  2750.     NumberFormat.getDefaultCurrency() and 
  2751. NumberFormat.getDefaultPercent().
  2752.  
  2753.     SOLUTION - This bug has been fixed.
  2754.  
  2755. -----------------------------------------------------------------------
  2756. Copyright ⌐ 1998 Sun Microsystems, Inc.
  2757. 901 San Antonio Rd., Palo Alto, CA 94303 USA
  2758. All rights reserved.
  2759.